home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Crypto⁄Encryption / PGP / PowerMac601 PGP 2.6.3i.sit / PowerMac601 PGP 2.6.3i / Volume II < prev    next >
Text File  |  1995-02-26  |  134KB  |  2,887 lines

  1.  
  2.  
  3.                 Phil's Pretty Good Software
  4.                         Presents
  5.  
  6.                         =======
  7.                           PGP™
  8.                         =======
  9.  
  10.                     Pretty Good™ Privacy
  11.             Public Key Encryption for the Masses
  12.  
  13.  
  14.                 -------------------------
  15.                     PGP™ User's Guide
  16.                 Volume II: Special Topics
  17.                 -------------------------
  18.                    by Philip Zimmermann
  19.                   Revised 11 October 94
  20.  
  21.  
  22.                 PGP Version 2.6.2 - 11 Oct 94
  23.                          Software by
  24.              Philip Zimmermann, and many others.
  25.  
  26.  
  27.  
  28.  
  29. Synopsis:  PGP™ uses public-key encryption to protect E-mail and
  30. data files.  Communicate securely with people you've never met, with
  31. no secure channels needed for prior exchange of keys.  PGP is well
  32. featured and fast, with sophisticated key management, digital
  33. signatures, data compression, and good ergonomic design.
  34.  
  35.  
  36. Software and documentation © Copyright 1990-1994 Philip Zimmermann.
  37. All rights reserved.  For information on PGP licensing, distribution,
  38. copyrights, patents, trademarks, liability limitations, and export
  39. controls, see the "Legal Issues" section.  Distributed by the
  40. Massachusetts Institute of Technology.
  41.  
  42.  
  43.  
  44. Contents
  45. ========
  46.  
  47. Quick Overview
  48. Special Topics
  49.   Selecting Keys via Key ID
  50.   Separating Signatures from Messages
  51.   Decrypting the Message and Leaving the Signature on it
  52.   Sending ASCII Text Files Across Different Machine Environments
  53.   Using PGP as a Better Uuencode
  54.   Leaving No Traces of Plaintext on the Disk
  55.   Displaying Decrypted Plaintext on Your Screen
  56.   Making a Message For Her Eyes Only
  57.   Preserving the Original Plaintext Filename
  58.   Editing Your User ID or Pass Phrase
  59.   Editing the Trust Parameters for a Public Key
  60.   Checking If Everything is OK on Your Public Key Ring
  61.   Verifying a Public Key Over the Phone
  62.   Handling Large Public Keyrings
  63.   Using PGP as a Unix-style Filter
  64.   Suppressing Unnecessary Questions:  BATCHMODE
  65.   Force "Yes" Answer to Confirmation Questions:  FORCE
  66.   PGP Returns Exit Status to the Shell
  67.   Environmental Variable for Pass Phrase
  68.   Setting Parameters in the PGP Configuration File
  69.     TMP - Directory Pathname for Temporary Files
  70.     LANGUAGE - Foreign Language Selector
  71.     MYNAME - Default User ID for Making Signatures
  72.     TEXTMODE - Assuming Plaintext is a Text File
  73.     CHARSET - Specifies Local Character Set for Text Files
  74.     ARMOR - Enable ASCII Armor Output
  75.     ARMORLINES - Size of ASCII Armor Multipart Files
  76.     KEEPBINARY - Keep Binary Ciphertext Files After Decrypting
  77.     COMPRESS - Enable Compression
  78.     COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed
  79.     MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed
  80.     CERT_DEPTH - How Deep May Introducers Be Nested
  81.     BAKRING - Filename for Backup Secret Keyring
  82.     PUBRING - Filename for Your Public Keyring
  83.     SECRING - Filename for Your Secret Keyring
  84.     RANDSEED - Filename for Random Number Seed
  85.     PAGER - Selects Shell Command to Display Plaintext Output
  86.     SHOWPASS - Echo Pass Phrase to User
  87.     TZFIX - Timezone Adjustment
  88.     CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text
  89.     VERBOSE - Quiet, Normal, or Verbose Messages
  90.     INTERACTIVE - Ask for Confirmation for Key Adds
  91.     NOMANUAL - Let PGP Generate Keys Without the Manual
  92.   A Peek Under the Hood
  93.     Random Numbers
  94.     PGP's Conventional Encryption Algorithm
  95.     Data Compression
  96.     Message Digests and Digital Signatures
  97.   Compatibility with Previous and Future Versions of PGP
  98. Vulnerabilities
  99.   Compromised Pass Phrase and Secret Key
  100.   Public Key Tampering
  101.   "Not Quite Deleted" Files
  102.   Viruses and Trojan Horses
  103.   Physical Security Breach
  104.   Tempest Attacks
  105.   Exposure on Multi-user Systems
  106.   Traffic Analysis
  107.   Protecting Against Bogus Timestamps
  108.   Cryptanalysis
  109. Legal Issues
  110.   Trademarks, Copyrights, and Warranties
  111.   Patent Rights on the Algorithms
  112.   Freeware Status and Restrictions
  113.   Restrictions on Commercial Use of PGP
  114.   Other Licensing Restrictions
  115.   Distribution
  116.   Export Controls
  117.   Philip Zimmermann's Legal Situation
  118. Other Sources of Information on PGP
  119.   Where to Get a Commercial Version of PGP
  120.   Reporting PGP Bugs
  121.   Fan Mail, Updates, and News
  122.   Computer-Related Political Groups
  123.   Recommended Readings
  124.   To Contact the Author
  125. Appendix A:  Where to Get PGP
  126.  
  127.  
  128.  
  129. Quick Overview
  130. ==============
  131.  
  132. Pretty Good™ Privacy (PGP), from Phil's Pretty Good Software, is a
  133. high security cryptographic software application for MSDOS, Unix,
  134. VAX/VMS, and other computers.  PGP combines the convenience of the
  135. Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of
  136. conventional cryptography, message digests for digital signatures,
  137. data compression before encryption, good ergonomic design, and
  138. sophisticated key management. 
  139.  
  140. This volume II of the PGP User's Guide covers advanced topics about
  141. PGP that were not covered in the "PGP User's Guide, Volume I:
  142. Essential Topics".  You should first read the Essential Topics
  143. volume, or this manual won't make much sense to you.  Reading this
  144. Special Topics volume is optional, except for the legal issues
  145. section, which everyone should read.
  146.  
  147.  
  148.  
  149. Special Topics
  150. ===============
  151.  
  152.  
  153. Selecting Keys via Key ID
  154. -------------------------
  155.  
  156. In all commands that let the user type a user ID or fragment of a
  157. user ID to select a key, the hexadecimal key ID may be used instead. 
  158. Just use the key ID, with a prefix of "0x", in place of the user ID. 
  159. For example:
  160.  
  161.     pgp -kv 0x67F7
  162.  
  163. This would display all keys that had 67F7 as part of their key IDs.
  164.  
  165. This feature is particularly useful if you have two different keys
  166. from the same person, with the same user ID.  You can unambiguously
  167. pick which key you want by specifying the key ID.
  168.  
  169.  
  170. Separating Signatures from Messages
  171. -----------------------------------
  172.  
  173. Normally, signature certificates are physically attached to the text
  174. they sign.  This makes it convenient in simple cases to check
  175. signatures.  It is desirable in some circumstances to have signature
  176. certificates stored separately from the messages they sign.  It is
  177. possible to generate signature certificates that are detached from
  178. the text they sign.  To do this, combine the 'b' (break) option with
  179. the 's' (sign) option.  For example:
  180.  
  181.     pgp -sb letter.txt
  182.  
  183. This example produces an isolated signature certificate in a file
  184. called "letter.sig".  The contents of letter.txt are not appended to
  185. the signature certificate.
  186.  
  187. After creating the signature certificate file (letter.sig in the
  188. above example), send it along with the original text file to the
  189. recipient.  The recipient must have both files to check the signature
  190. integrity.  When the recipient attempts to process the signature
  191. file, PGP notices that there is no text in the same file with the
  192. signature and prompts the user for the filename of the text. Only
  193. then can PGP properly check the signature integrity.  If the
  194. recipient knows in advance that the signature is detached from the
  195. text file, she can specify both filenames on the command line:
  196.  
  197.     pgp letter.sig letter.txt
  198. or: pgp letter letter.txt
  199.  
  200. PGP will not have to prompt for the text file name in this case.
  201.  
  202. A detached signature certificate is useful if you want to keep the
  203. signature certificate in a separate certificate log.  A detached
  204. signature of an executable program is also useful for detecting a
  205. subsequent virus infection.  It is also useful if more than one party
  206. must sign a document such as a legal contract, without nesting
  207. signatures.  Each person's signature is independent.
  208.  
  209. If you receive a ciphertext file that has the signature certificate
  210. glued to the message, you can still pry the signature certificate
  211. away from the message during the decryption.  You can do this with
  212. the -b option during decrypt, like so:
  213.  
  214.     pgp -b letter
  215.  
  216. This decrypts the letter.pgp file and if there is a signature in it,
  217. PGP checks the signature and detaches it from the rest of the
  218. message, storing it in the file letter.sig.
  219.  
  220.  
  221. Decrypting the Message and Leaving the Signature on it
  222. ------------------------------------------------------
  223.  
  224. Usually, you want PGP to completely unravel a ciphertext file,
  225. decrypting it and checking the nested signature if there is one,
  226. peeling away the layers until you are left with only the original
  227. plaintext file.
  228.  
  229. But sometimes you want to decrypt an encrypted file, and leave the
  230. inner signature still attached, so that you are left with a decrypted
  231. signed message.  This may be useful if you want to send a copy of a
  232. signed document to a third party, perhaps re-enciphering it.  For
  233. example, suppose you get a message signed by Charlie, encrypted to
  234. you.  You want to decrypt it, and, leaving Charlie's signature on it,
  235. you want to send it to Alice, perhaps re-enciphering it with Alice's
  236. public key.  No problem.  PGP can handle that.
  237.  
  238. To simply decrypt a message and leave the signature on it intact,
  239. type:
  240.  
  241.     pgp -d letter
  242.  
  243. This decrypts letter.pgp, and if there is an inner signature, it is
  244. left intact with the decrypted plaintext in the output file.
  245.  
  246. Now you can archive it, or maybe re-encrypt it and send it to someone
  247. else.
  248.  
  249.  
  250.  
  251. Sending ASCII Text Files Across Different Machine Environments
  252. --------------------------------------------------------------
  253.  
  254. You may use PGP to encrypt any kind of plaintext file, binary 8-bit
  255. data or ASCII text.  Probably the most common usage of PGP will be for
  256. E-mail, when the plaintext is ASCII text.  
  257.  
  258. ASCII text is sometimes represented differently on different
  259. machines.  For example, on an MSDOS system, all lines of ASCII text
  260. are terminated with a carriage return followed by a linefeed.  On a
  261. Unix system, all lines end with just a linefeed.  On a Macintosh, all
  262. lines end with just a carriage return.  This is a sad fact of life.
  263.  
  264. Normal unencrypted ASCII text messages are often automatically
  265. translated to some common "canonical" form when they are transmitted
  266. from one machine to another.  Canonical text has a carriage return
  267. and a linefeed at the end of each line of text.  For example, the
  268. popular KERMIT communication protocol can convert text to canonical
  269. form when transmitting it to another system.  This gets converted
  270. back to local text line terminators by the receiving KERMIT.  This
  271. makes it easy to share text files across different systems.
  272.  
  273. But encrypted text cannot be automatically converted by a
  274. communication protocol, because the plaintext is hidden by
  275. encipherment.  To remedy this inconvenience, PGP lets you specify
  276. that the plaintext should be treated as ASCII text (not binary data)
  277. and should be converted to canonical text form before it gets
  278. encrypted.  At the receiving end, the decrypted plaintext is
  279. automatically converted back to whatever text form is appropriate for
  280. the local environment.
  281.  
  282. To make PGP assume the plaintext is text that should be converted to
  283. canonical text before encryption, just add the "t" option when
  284. encrypting or signing a message, like so:
  285.  
  286.    pgp -et message.txt her_userid
  287.  
  288. This mode is automatically turned off if PGP detects that the
  289. plaintext file contains what it thinks is non-text binary data.
  290.  
  291. If you need to use the -t option a lot, you can just turn on the
  292. TEXTMODE flag in the PGP configuration file.  That's what I do.
  293.  
  294. For PGP users that use non-English 8-bit character sets, when PGP 
  295. converts text to canonical form, it may convert data from the local
  296. character set into the LATIN1 (ISO 8859-1 Latin Alphabet 1) character
  297. set, depending on the setting of the CHARSET parameter in the PGP
  298. configuration file.  LATIN1 is a superset of ASCII, with extra
  299. characters added for many European languages.
  300.  
  301.  
  302.  
  303. Using PGP as a Better Uuencode
  304. ------------------------------
  305.  
  306. A lot of people in the Unix world send binary data files through
  307. E-mail channels by using the Unix "uuencode" utility to convert the
  308. file into printable ASCII characters that can be sent via email.  No
  309. encryption is involved, so neither the sender nor the recipient need
  310. any special keys.  The uuencode format was designed for a similar
  311. purpose as PGP's radix-64 ASCII transport armor format described in
  312. the "Sending Ciphertext Through E-mail Channels: Radix-64 Format"
  313. section, but not as good.  A different radix-64 character set is
  314. used.  Uuencode has its problems, such as 1) several slightly
  315. incompatible character sets for different versions of uuencode in the
  316. MSDOS and Unix worlds, and 2) the data can be corrupted by some
  317. E-mail gateways that strip trailing blanks or do other modifications
  318. to the character set used by uuencode.
  319.  
  320. PGP may be used in a manner that offers the same general features as
  321. uuencode, and then some.  You can get PGP to just convert a file into
  322. PGP's radix-64 ASCII transport armor format, but you don't have to
  323. encrypt the file or sign it, so no keys are needed by either party.
  324. Simply use the -a option alone.  For example:
  325.  
  326.     pgp -a filename
  327.  
  328. This would produce a radix-64 armored file called "filename.asc".
  329.  
  330. If you read the "Sending Ciphertext Through E-mail Channels: Radix-64
  331. Format" section, you will see that PGP's approach offers several
  332. important advantages over the uuencode approach:
  333.  
  334.  * PGP will break big files up into chunks small enough to E-mail.
  335.  * PGP will append a CRC error detection code to each chunk.
  336.  * PGP will attempt to compress the data before converting it to
  337.    radix-64 armor.
  338.  * PGP's radix-64 character set is more resilient to E-mail character
  339.    conversions than the one used by uuencode.
  340.  * Textfiles can be converted by the sender to canonical text 
  341.    format, as explained in the "Sending ASCII Text Files Across
  342.    Different Machine Environments" section.
  343.  
  344. The recipient can restore the sender's original filename by
  345. unwrapping the message with PGP's -p option.  You can use "pgp -a" in
  346. any situation in which you could have used uuencode, if the recipient
  347. also has PGP.  PGP is a better uuencode than uuencode.
  348.  
  349.  
  350.  
  351. Leaving No Traces of Plaintext on the Disk
  352. ------------------------------------------
  353.  
  354. After PGP makes a ciphertext file for you, you can have PGP
  355. automatically overwrite the plaintext file and delete it, leaving no
  356. trace of plaintext on the disk so that no one can recover it later
  357. using a disk block scanning utility.  This is useful if the plaintext
  358. file contains sensitive information that you don't want to keep
  359. around.
  360.  
  361. To wipe out the plaintext file after producing the ciphertext file,
  362. just add the "w" (wipe) option when encrypting or signing a message,
  363. like so:
  364.  
  365.     pgp -esw message.txt her_userid
  366.  
  367. This example creates the ciphertext file "message.pgp", and the 
  368. plaintext file "message.txt" is destroyed beyond recovery.
  369.  
  370. Obviously, you should be careful with this option.  Also note that
  371. this will not wipe out any fragments of plaintext that your word
  372. processor might have created on the disk while you were editing the
  373. message before running PGP.  Most word processors create backup
  374. files, scratch files, or both.  Also, it overwrites the file only
  375. once, which is enough to thwart conventional disk recovery efforts,
  376. but not enough to withstand a determined and sophisticated effort to
  377. recover the faint magnetic traces of the data using special disk
  378. recovery hardware.
  379.  
  380.  
  381.  
  382. Displaying Decrypted Plaintext on Your Screen
  383. ---------------------------------------------
  384.  
  385. To view the decrypted plaintext output on your screen (like the
  386. Unix-style "more" command), without writing it to a file, use the -m
  387. (more) option while decrypting:
  388.  
  389.      pgp -m ciphertextfile
  390.  
  391. This displays the decrypted plaintext display on your screen one
  392. screenful at a time.
  393.  
  394.  
  395.  
  396. Making a Message For Her Eyes Only
  397. ----------------------------------
  398.  
  399. To specify that the recipient's decrypted plaintext will be shown
  400. ONLY on her screen and will not be saved to disk, add the -m option:
  401.  
  402.      pgp -sem message.txt her_userid
  403.  
  404. Later, when the recipient decrypts the ciphertext with her secret key
  405. and pass phrase, the plaintext will be displayed on her screen but
  406. will not be saved to disk.  The text will be displayed as it would if
  407. she used the Unix "more" command, one screenful at a time.  If she
  408. wants to read the message again, she will have to decrypt the
  409. ciphertext again.
  410.  
  411. This feature is the safest way for you to prevent your sensitive
  412. message from being inadvertently left on the recipient's disk.  This
  413. feature was added at the request of a user who wanted to send
  414. intimate messages to his lover, but was afraid she might accidentally
  415. leave the decrypted messages on her husband's computer.
  416.  
  417. Note that this feature will not prevent a clever and determined
  418. person from finding a way to save the decrypted plaintext to disk--
  419. it's to help prevent a casual user from doing it inadvertently.
  420.  
  421.  
  422.  
  423. Preserving the Original Plaintext Filename
  424. ------------------------------------------
  425.  
  426. Normally, PGP names the decrypted plaintext output file with a name
  427. similar to the input ciphertext filename, but dropping the 
  428. extension.  Or, you can override that convention by specifying an
  429. output plaintext filename on the command line with the -o option.
  430. For most E-mail, this is a reasonable way to name the plaintext file,
  431. because you get to decide its name when you decipher it, and your
  432. typical E-mail messages often come from useless original plaintext
  433. filenames like "to_phil.txt".  
  434.  
  435. But when PGP encrypts a plaintext file, it always saves the original
  436. filename and attaches it to the plaintext before it compresses and
  437. encrypts the plaintext.  Normally, this hidden original filename is
  438. discarded by PGP when it decrypts, but you can tell PGP you want to
  439. preserve the original plaintext filename and use it as the name of
  440. the decrypted plaintext output file.  This is useful if PGP is used
  441. on files whose names are important to preserve.
  442.  
  443. To recover the original plaintext filename while decrypting, add 
  444. the -p option, like so:
  445.  
  446.      pgp -p ciphertextfile
  447.  
  448. I usually don't use this option, because if I did, about half of my
  449. incoming E-mail would decrypt to the same plaintext filenames of
  450. "to_phil.txt" or "prz.txt".
  451.  
  452.  
  453.  
  454. Editing Your User ID or Pass Phrase
  455. -----------------------------------
  456.  
  457. Sometimes you may need to change your pass phrase, perhaps because
  458. someone looked over your shoulder while you typed it in.  
  459.  
  460. Or you may need to change your user ID, because you got married and
  461. changed your name, or maybe you changed your E-mail address.  Or
  462. maybe you want to add a second or third user ID to your key, because
  463. you may be known by more than one name or E-mail address or job
  464. title.  PGP lets you attach more than one user ID to your key, any
  465. one of which may be used to look up your key on the key ring.
  466.  
  467. To edit your own userid or pass phrase for your secret key:
  468.  
  469.      pgp -ke userid [keyring]
  470.  
  471. PGP prompts you for a new user ID or a new pass phrase.
  472.  
  473. If you edit your user ID, PGP actually adds a new user ID, without
  474. deleting the old one.  If you want to delete an old user ID, you will
  475. have to do that in a separate operation.
  476.  
  477. The optional [keyring] parameter, if specified, must be a public
  478. keyring, not a secret keyring.  The userid field must be your own
  479. userid, which PGP knows is yours because it appears on both your
  480. public keyring and your secret keyring.  Both keyrings will be
  481. updated, even though you only specified the public keyring.
  482.  
  483. The -ke command works differently depending on whether you use it on
  484. a public or secret key.  It can also be used to edit the trust
  485. parameters for a public key.
  486.  
  487.  
  488. Editing the Trust Parameters for a Public Key
  489. ---------------------------------------------
  490.  
  491. Sometimes you need to alter the trust parameters for a public key on
  492. your public key ring.  For a discussion on what these trust
  493. parameters mean, see the section "How Does PGP Keep Track of Which
  494. Keys are Valid?" in the Essential Topics volume of the PGP User's
  495. Guide.
  496.  
  497. To edit the trust parameters for a public key:
  498.  
  499.      pgp -ke userid [keyring]
  500.  
  501. The optional [keyring] parameter, if specified, must be a public
  502. keyring, not a secret keyring.
  503.  
  504.  
  505.  
  506. Checking If Everything is OK on Your Public Key Ring
  507. ----------------------------------------------------
  508.  
  509. Normally, PGP automatically checks any new keys or signatures on your
  510. public key ring and updates all the trust parameters and validity
  511. scores.  In theory, it keeps all the key validity status information
  512. up to date as material is added to or deleted from your public key
  513. ring.  But perhaps you may want to explicitly force PGP to perform a
  514. comprehensive analysis of your public key ring, checking all the
  515. certifying signatures, checking the trust parameters, updating all
  516. the validity scores, and checking your own ultimately-trusted key
  517. against a backup copy on a write-protected floppy disk.  It may be a
  518. good idea to do this hygienic maintenance periodically to make sure
  519. nothing is wrong with your public key ring.  To force PGP to perform
  520. a full analysis of your public key ring, use the -kc (key ring check)
  521. command:
  522.  
  523.      pgp -kc
  524.  
  525. You can also make PGP check all the signatures for just a single
  526. selected public key by:
  527.  
  528.      pgp -kc userid [keyring]
  529.  
  530. For further information on how the backup copy of your own key is
  531. checked, see the description of the BAKRING parameter in the
  532. configuration file section of this manual.
  533.  
  534.  
  535.  
  536. Verifying a Public Key Over the Phone
  537. -------------------------------------
  538.  
  539. If you get a public key from someone that is not certified by anyone
  540. you trust, how can you tell if it's really their key?  The best way
  541. to verify an uncertified key is to verify it over some independent
  542. channel other than the one you received the key through.  One
  543. convenient way to tell, if you know this person and would recognize
  544. them on the phone, is to call them and verify their key over the
  545. telephone.  Rather than reading their whole tiresome (ASCII-armored)
  546. key to them over the phone, you can just read their key's
  547. "fingerprint" to them.  To see this fingerprint, use the -kvc
  548. command:
  549.  
  550.      pgp -kvc userid [keyring]
  551.  
  552. This will display the key with the 16-byte digest of the public key
  553. components.  Read this 16-byte fingerprint to the key's owner on the
  554. phone, while she checks it against her own, using the same -kvc
  555. command at her end.  
  556.  
  557. You can both verify each other's keys this way, and then you can sign
  558. each other's keys with confidence.  This is a safe and convenient way
  559. to get the key trust network started for your circle of friends.
  560.  
  561. Note that sending a key fingerprint via E-mail is not the best way to
  562. verify the key, because E-mail can be intercepted and modified.  It's
  563. best to use a different channel than the one that was used to send
  564. the key itself.  A good combination is to send the key via E-mail,
  565. and the key fingerprint via a voice telephone conversation.  Some
  566. people distribute their key fingerprint on their business cards,
  567. which looks really cool.
  568.  
  569. For current versions of PGP, the key fingerprint is computed using 
  570. the MD5 hash function.  A future version of PGP will optionally use a
  571. new and different hash function, SHA, instead of MD5.
  572.  
  573. If you don't know me, please don't call me to verify my key over the
  574. phone-- I get too many calls like that.  Since every PGP user has a
  575. copy of my public key, no one could tamper with all the copies that
  576. are out there.  The discrepancy would soon be noticed by someone who
  577. checked it from more than one source, and word would soon get out on
  578. the Internet.
  579.  
  580. For those of you who want to verify my public key (included in the
  581. standard PGP release package), here are the particulars:
  582.  
  583.   UserID: "Philip R. Zimmermann <prz@acm.org>"
  584.   Key Size: 1024 bits;  Creation date: 21 May 1993;  KeyID: C7A966DD
  585.   Key fingerprint:  9E 94 45 13 39 83 5F 70  7B E7 D8 ED C4 BE 5A A6
  586.  
  587. The information printed above conceivably could still be tampered
  588. with in the electronic distribution of the PGP User's Guide.  But if
  589. you read this in the printed version of the manual, available in
  590. bookstores from MIT Press, it's a safe bet that it really is my own
  591. key's fingerprint.
  592.  
  593.  
  594. Handling Large Public Keyrings
  595. ------------------------------
  596.  
  597. PGP was originally designed for handling small personal keyrings for
  598. keeping all your friends on, like a personal rolodex.  A couple
  599. hundred keys is a reasonable size for such a keyring.  But as PGP has
  600. become more popular, people are now trying to add other large
  601. keyrings to their own keyring.  Sometimes this involves adding
  602. thousands of keys to your keyring.  PGP, in its present form, cannot
  603. perform this operation in a reasonable period of time, while you wait
  604. at your keyboard.  Not for huge keyrings.
  605.  
  606. You may want to add a huge "imported" keyring to your own keyring,
  607. because you are only interested in a few dozen keys on the bigger
  608. keyring you are bringing in.  If that's all you want from the other
  609. keyring, it would be more efficient if you extract the few keys you
  610. need from the big foreign keyring, and then add just these few keys
  611. to your own keyring.  Use the -kx command to extract them from the
  612. foreign keyring, specifying the keyring name on the command line. 
  613. Then add these extracted keys to your own keyring.
  614.  
  615. The real solution is to improve PGP to use advanced database
  616. techniques to manage large keyrings efficiently.  We are working on
  617. this, and should have it done Real Soon Now.  Until this happens, you
  618. will just have to use smaller keyrings, or be patient.
  619.  
  620.  
  621.  
  622. Using PGP as a Unix-style Filter
  623. --------------------------------
  624.  
  625. Unix fans are accustomed to using Unix "pipes" to make two
  626. applications work together.  The output of one application can be
  627. directly fed through a pipe to be read as input to another
  628. application.  For this to work, the applications must be capable of
  629. reading the raw material from "standard input" and writing the
  630. finished output to "standard output".  PGP can operate in this mode.
  631. If you don't understand what this means, then you probably don't need
  632. this feature.
  633.  
  634. To use a Unix-style filter mode, reading from standard input and
  635. writing to standard output, add the -f option, like so:
  636.  
  637.      pgp -feast her_userid <inputfile >outputfile
  638.  
  639. This feature makes it easier to make PGP work with electronic mail
  640. applications.
  641.  
  642. When using PGP in filter mode to decrypt a ciphertext file, you may
  643. find it useful to use the PGPPASS environmental variable to hold the
  644. pass phrase, so that you won't be prompted for it.  The PGPPASS
  645. feature is explained below.
  646.  
  647.  
  648. Suppressing Unnecessary Questions:  BATCHMODE
  649. ----------------------------------------------
  650.  
  651. With the BATCHMODE flag enabled on the command line, PGP will not ask
  652. any unnecessary questions or prompt for alternate filenames.  Here
  653. is an example of how to set this flag:
  654.  
  655.     pgp +batchmode cipherfile 
  656.  
  657. This is useful for running PGP non-interactively from Unix shell
  658. scripts or MSDOS batch files.  Some key management commands still
  659. need user interaction even when BATCHMODE is on, so shell scripts may
  660. need to avoid them.  
  661.  
  662. BATCHMODE may also be enabled to check the validity of a signature on
  663. a file.  If there was no signature on the file, the exit code is 1. 
  664. If it had a signature that was good, the exit code is 0.
  665.  
  666.  
  667. Force "Yes" Answer to Confirmation Questions:  FORCE
  668. ----------------------------------------------------
  669.  
  670. This command-line flag makes PGP assume "yes" for the user response
  671. to the confirmation request to overwrite an existing file, or when
  672. removing a key from the keyring via the -kr command.  Here is an
  673. example of how to set this flag:
  674.  
  675.     pgp +force cipherfile 
  676. or:
  677.     pgp -kr +force Smith
  678.  
  679. This feature is useful for running PGP non-interactively from a Unix
  680. shell script or MSDOS batch file.
  681.  
  682.  
  683.  
  684. PGP Returns Exit Status to the Shell
  685. ------------------------------------
  686.  
  687. To facilitate running PGP in "batch" mode, such as from an MSDOS
  688. ".bat" file or from a Unix shell script, PGP returns an error exit
  689. status to the shell.  An exit status code of zero means normal exit,
  690. while a nonzero exit status indicates some kind of error occurred.
  691. Different error exit conditions return different exit status codes to
  692. the shell.
  693.  
  694.  
  695.  
  696. Environmental Variable for Pass Phrase
  697. --------------------------------------
  698.  
  699. Normally, PGP prompts the user to type a pass phrase whenever PGP 
  700. needs a pass phrase to unlock a secret key.  But it is possible to
  701. store the pass phrase in an environmental variable from your
  702. operating system's command shell.  The environmental variable PGPPASS
  703. can be used to hold the pass phrase that PGP will attempt to use
  704. first.  If the pass phrase stored in PGPPASS is incorrect, PGP 
  705. recovers by prompting the user for the correct pass phrase.
  706.  
  707. For example, on MSDOS, the shell command:
  708.  
  709.     SET PGPPASS=zaphod beeblebrox for president
  710.  
  711. would eliminate the prompt for the pass phrase if the pass phrase
  712. were indeed "zaphod beeblebrox for president". 
  713.  
  714. This dangerous feature makes your life more convenient if you have to
  715. regularly deal with a large number of incoming messages addressed to
  716. your secret key, by eliminating the need for you to repeatedly type
  717. in your pass phrase every time you run PGP.
  718.  
  719. I added this feature because of popular demand.  However, this is a
  720. somewhat dangerous feature, because it keeps your precious pass
  721. phrase stored somewhere other than just in your brain.  Even worse,
  722. if you are particularly reckless, it may even be stored on a disk on
  723. the same computer as your secret key.  It would be particularly
  724. dangerous and stupid if you were to install this command in a batch
  725. or script file, such as the MSDOS AUTOEXEC.BAT file.  Someone could
  726. come along on your lunch hour and steal both your secret key ring and
  727. the file containing your pass phrase.  
  728.  
  729. I can't emphasize the importance of this risk enough.  If you are
  730. contemplating using this feature, be sure to read the sections
  731. "Exposure on Multi-user Systems" and "How to Protect Secret Keys from
  732. Disclosure" in this volume and in the Essential Topics volume of the 
  733. PGP User's Guide.
  734.  
  735. If you must use this feature, the safest way to do it would be to
  736. just manually type in the shell command to set PGPPASS every time you
  737. boot your machine to start using PGP, and then erase it or turn off
  738. your machine when you are done.  And you should definitely never do
  739. it in an environment where someone else may have access to your
  740. machine.  Someone could come along and simply ask your computer to
  741. display the contents of PGPPASS.
  742.  
  743. Sometimes you want to pass the pass phrase into PGP from another
  744. application, such as an E-mail package.  In some cases, it may not
  745. always be desirable to use the PGPPASS variable for that purpose. 
  746. There is another way to pass your pass phrase into PGP from another
  747. application.  Use the "-z" command line option.  This option is
  748. designed primarily for invoking PGP from inside an E-mail package. 
  749. The pass phrase follows the -z option on the command line.  There are
  750. risks associated with using this approach, similar to those risks
  751. described above for using the PGPPASS variable.
  752.  
  753.  
  754. Setting Parameters in the PGP Configuration File
  755. ================================================
  756.  
  757. PGP has a number of user-settable parameters that can be defined in a
  758. special PGP configuration text file called "config.txt", in the
  759. directory pointed to by the shell environmental variable PGPPATH. 
  760. Having a configuration file enables the user to define various flags
  761. and parameters for PGP without the burden of having to always define
  762. these parameters in the PGP command line.
  763.  
  764. The filename "config.txt" has been in use for a long time by PGP, but
  765. some folks have pointed out that it may be at odds with naming
  766. conventions for configuration files for specific operating systems. 
  767. Accordingly, PGP now tries to open this filename only after first
  768. trying to open the file ".pgprc" on Unix platforms, and "pgp.ini" on
  769. other platforms, in the same directory that PGP would look for
  770. "config.txt".
  771.  
  772. Configuration parameters may be assigned integer values, character
  773. string values, or on/off values, depending on what kind of
  774. configuration parameter it is.  A sample configuration file is
  775. provided with PGP, so you can see some examples.
  776.  
  777. In the configuration file, blank lines are ignored, as is anything
  778. following the '#' comment character.  Keywords are not
  779. case-sensitive.  
  780.  
  781. Here is a short sample fragment of a typical configuration file:
  782.  
  783.    # TMP is the directory for PGP scratch files, such as a RAM disk.
  784.    TMP = "e:\"    # Can be overridden by environment variable TMP.
  785.    Armor = on     # Use -a flag for ASCII armor whenever applicable.
  786.    # CERT_DEPTH is how deeply introducers may introduce introducers.
  787.    cert_depth = 3
  788.  
  789. If some configuration parameters are not defined in the configuration
  790. file, or if there is no configuration file, or if PGP can't find the
  791. configuration file, the values for the configuration parameters
  792. default to some reasonable value.
  793.  
  794. Note that it is also possible to set these same configuration
  795. parameters directly from the PGP command line, by preceding the
  796. parameter setting with a "+" character.  For example, the following
  797. two PGP commands produce the same effect:
  798.  
  799.      pgp -e +armor=on message.txt smith
  800. or:  pgp -ea message.txt smith
  801.  
  802.  
  803. The following is a summary of the various parameters than may be
  804. defined in the configuration file.
  805.  
  806.  
  807. TMP - Directory Pathname for Temporary Files
  808. --------------------------------------------
  809.  
  810. Default setting:  TMP = ""
  811.  
  812. The configuration parameter TMP specifies what directory to use for
  813. PGP's temporary scratch files.  The best place to put them is on a
  814. RAM disk, if you have one.  That speeds things up quite a bit, and
  815. increases security somewhat.  If TMP is undefined, the temporary
  816. files go in the current directory.  If the shell environmental
  817. variable TMP is defined, PGP instead uses that to specify where the
  818. temporary files should go.
  819.  
  820.  
  821. LANGUAGE - Foreign Language Selector
  822. ------------------------------------
  823.  
  824. Default setting:  LANGUAGE = "en"
  825.  
  826. PGP displays various prompts, warning messages, and advisories to the
  827. user on the screen.  For example, messages such as "File not found.",
  828. or "Please enter your pass phrase:".  These messages are normally in
  829. English.  But it is possible to get PGP to display its messages to
  830. the user in other languages, without having to modify the PGP
  831. executable program.
  832.  
  833. A number of people in various countries have translated all of PGP's
  834. display messages, warnings, and prompts into their native languages. 
  835. These hundreds of translated message strings have been placed in a
  836. special text file called "language.txt", distributed with the PGP
  837. release.  The messages are stored in this file in English, Spanish,
  838. Dutch, German, French, Italian, Russian, Latvian, and Lithuanian. 
  839. Other languages may be added later.  
  840.  
  841. The configuration parameter LANGUAGE specifies what language to
  842. display these messages in.  LANGUAGE may be set to "en" for English,
  843. "es" for Spanish, "de" for German, "nl" for Dutch, "fr" for French,
  844. "it" for Italian, "ru" for Russian, "lt3" for Lithuanian, "lv" for
  845. Latvian, "esp" for Esperanto.  For example, if this line appeared in
  846. the configuration file:
  847.  
  848.     LANGUAGE = "fr"
  849.  
  850. PGP would select French as the language for its display messages.
  851. The default setting is English.
  852.  
  853. When PGP needs to display a message to the user, it looks in the
  854. "language.txt" file for the equivalent message string in the selected
  855. foreign language and displays that translated message to the user.
  856. If PGP can't find the language string file, or if the selected
  857. language is not in the file, or if that one phrase is not translated
  858. into the selected language in the file, or if that phrase is missing
  859. entirely from the file, PGP displays the message in English.
  860.  
  861. To conserve disk space, most foreign translations are not included 
  862. in the standard PGP release package, but are available separately.
  863.  
  864.  
  865. MYNAME - Default User ID for Making Signatures
  866. ----------------------------------------------
  867.  
  868. Default setting:  MYNAME = ""
  869.  
  870. The configuration parameter MYNAME specifies the default user ID to
  871. use to select the secret key for making signatures.  If MYNAME is not
  872. defined, the most recent secret key you installed on your secret key
  873. ring will be used.  The user may also override this setting by
  874. specifying a user ID on the PGP command line with the -u option.
  875.  
  876.  
  877. TEXTMODE - Assuming Plaintext is a Text File
  878. --------------------------------------------
  879.  
  880. Default setting:  TEXTMODE = off
  881.  
  882. The configuration parameter TEXTMODE is equivalent to the -t command
  883. line option.  If enabled, it causes PGP to assume the plaintext is a
  884. text file, not a binary file, and converts it to "canonical text"
  885. before encrypting it.  Canonical text has a carriage return and a
  886. linefeed at the end of each line of text.
  887.  
  888. This mode will be automatically turned off if PGP detects that the
  889. plaintext file contains what it thinks is non-text binary data.  If
  890. you intend to use PGP primarily for E-mail purposes, you should turn
  891. TEXTMODE=ON.
  892.  
  893. For VAX/VMS systems, the current version of PGP defaults TEXTMODE=ON.
  894.  
  895. For further details, see the section "Sending ASCII Text Files Across
  896. Different Machine Environments".
  897.  
  898.  
  899. CHARSET - Specifies Local Character Set for Text Files
  900. ------------------------------------------------------
  901.  
  902. Default setting:  CHARSET = NOCONV
  903.  
  904. Because PGP must process messages in many non-English languages with
  905. non-ASCII character sets, you may have a need to tell PGP what local
  906. character set your machine uses.  This determines what character
  907. conversions are performed when converting plaintext files to and from
  908. canonical text format.  This is only a concern if you are in a
  909. non-English non-ASCII environment.
  910.  
  911. The configuration parameter CHARSET selects the local character set. 
  912. The choices are NOCONV (no conversion), LATIN1 (ISO 8859-1 Latin
  913. Alphabet 1), KOI8 (used by most Russian Unix systems), ALT_CODES
  914. (used by Russian MSDOS systems), ASCII, and CP850 (used by most
  915. western European languages on standard MSDOS PCs).
  916.  
  917. LATIN1 is the internal representation used by PGP for canonical text,
  918. so if you select LATIN1, no conversion is done.  Note also that PGP
  919. treats KOI8 as LATIN1, even though it is a completely different
  920. character set (Russian), because trying to convert KOI8 to either
  921. LATIN1 or CP850 would be futile anyway.  This means that setting
  922. CHARSET to NOCONV, LATIN1, or KOI8 are all equivalent to PGP.
  923.  
  924. If you use MSDOS and expect to send or receive traffic in western
  925. European languages, set CHARSET = "CP850".  This will make PGP
  926. convert incoming canonical text messages from LATIN1 to CP850 after
  927. decryption.  If you use the -t (textmode) option to convert to
  928. canonical text, PGP will convert your CP850 text to LATIN1 before
  929. encrypting it.
  930.  
  931. For further details, see the section "Sending ASCII Text Files Across
  932. Different Machine Environments".
  933.  
  934.  
  935. ARMOR - Enable ASCII Armor Output
  936. ---------------------------------
  937.  
  938. Default setting:  ARMOR = off
  939.  
  940. The configuration parameter ARMOR is equivalent to the -a command
  941. line option.  If enabled, it causes PGP to emit ciphertext or keys in
  942. ASCII Radix-64 format suitable for transporting through E-mail
  943. channels.  Output files are named with the ".asc" extension.
  944.  
  945. If you intend to use PGP primarily for E-mail purposes, you should
  946. turn ARMOR=ON.
  947.  
  948. For further details, see the section "Sending Ciphertext Through
  949. E-mail Channels: Radix-64 Format" in the Essential Topics volume. 
  950.  
  951.  
  952. ARMORLINES - Size of ASCII Armor Multipart Files
  953. ------------------------------------------------
  954.  
  955. Default setting:  ARMORLINES = 720
  956.  
  957. When PGP creates a very large ".asc" radix-64 file for sending
  958. ciphertext or keys through the E-mail, it breaks the file up into
  959. separate chunks small enough to send through Internet mail
  960. utilities.  Normally, Internet mailers prohibit files larger than
  961. about 50000 bytes, which means that if we restrict the number of
  962. lines to about 720, we'll be well within the limit.  The file chunks
  963. are named with suffixes ".as1", ".as2", ".as3", ... 
  964.  
  965. The configuration parameter ARMORLINES specifies the maximum number
  966. of lines to make each chunk in a multipart ".asc" file sequence.  If
  967. you set it to zero, PGP will not break up the file into chunks.
  968.  
  969. Fidonet E-mail files usually have an upper limit of about 32K bytes,
  970. so 450 lines would be appropriate for Fidonet environments.
  971.  
  972. For further details, see the section "Sending Ciphertext Through
  973. E-mail Channels: Radix-64 Format" in the Essential Topics volume.
  974.  
  975.  
  976. KEEPBINARY - Keep Binary Ciphertext Files After Decrypting
  977. ----------------------------------------------------------
  978.  
  979. Default setting:  KEEPBINARY = off
  980.  
  981. When PGP reads a ".asc" file, it recognizes that the file is in
  982. radix-64 format and will convert it back to binary before processing
  983. as it normally does, producing as a by-product a ".pgp" ciphertext
  984. file in binary form.  After further processing to decrypt the ".pgp"
  985. file, the final output file will be in normal plaintext form.
  986.  
  987. You may want to delete the binary ".pgp" intermediate file, or you
  988. may want PGP to delete it for you automatically.  You can still rerun
  989. PGP on the original ".asc" file.
  990.  
  991. The configuration parameter KEEPBINARY enables or disables keeping
  992. the intermediate ".pgp" file during decryption.
  993.  
  994. For further details, see the section "Sending Ciphertext Through
  995. E-mail Channels: Radix-64 Format" in the Essential Topics volume.
  996.  
  997.  
  998. COMPRESS - Enable Compression
  999. -----------------------------
  1000.  
  1001. Default setting:  COMPRESS = on
  1002.  
  1003. The configuration parameter COMPRESS enables or disables data
  1004. compression before encryption.  It is used mainly for debugging PGP. 
  1005. Normally, PGP attempts to compress the plaintext before it encrypts
  1006. it.  Generally, you should leave this alone and let PGP attempt to
  1007. compress the plaintext.
  1008.  
  1009.  
  1010. COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed
  1011. ------------------------------------------------------------------
  1012.  
  1013. Default setting:  COMPLETES_NEEDED = 1
  1014.  
  1015. The configuration parameter COMPLETES_NEEDED specifies the minimum
  1016. number of completely trusted introducers required to fully certify a
  1017. public key on your public key ring.  This gives you a way of tuning
  1018. PGP's skepticism.
  1019.  
  1020. For further details, see the section "How Does PGP Keep Track of 
  1021. Which Keys are Valid?" in the Essential Topics volume.
  1022.  
  1023.  
  1024. MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed
  1025. ------------------------------------------------------------------
  1026.  
  1027. Default setting:  MARGINALS_NEEDED = 2
  1028.  
  1029. The configuration parameter MARGINALS_NEEDED specifies the minimum
  1030. number of marginally trusted introducers required to fully certify a
  1031. public key on your public key ring.  This gives you a way of tuning
  1032. PGP's skepticism.
  1033.  
  1034. For further details, see the section "How Does PGP Keep Track of 
  1035. Which Keys are Valid?" in the Essential Topics volume.
  1036.  
  1037.  
  1038. CERT_DEPTH - How Deep May Introducers Be Nested
  1039. -----------------------------------------------
  1040.  
  1041. Default setting:  CERT_DEPTH = 4
  1042.  
  1043. The configuration parameter CERT_DEPTH specifies how many levels deep
  1044. you may nest introducers to certify other introducers to certify
  1045. public keys on your public key ring.  For example, If CERT_DEPTH is
  1046. set to 1, there may only be one layer of introducers below your own
  1047. ultimately-trusted key.  If that were the case, you would be required
  1048. to directly certify the public keys of all trusted introducers on
  1049. your key ring.  If you set CERT_DEPTH to 0, you could have no
  1050. introducers at all, and you would have to directly certify each and
  1051. every key on your public key ring in order to use it.  The minimum
  1052. CERT_DEPTH is 0, the maximum is 8.
  1053.  
  1054. For further details, see the section "How Does PGP Keep Track of 
  1055. Which Keys are Valid?" in the Essential Topics volume.
  1056.  
  1057.  
  1058. BAKRING - Filename for Backup Secret Keyring
  1059. --------------------------------------------
  1060.  
  1061. Default setting:  BAKRING = ""
  1062.  
  1063. All of the key certification that PGP does on your public key ring
  1064. ultimately depends on your own ultimately-trusted public key (or
  1065. keys).  To detect any tampering of your public key ring, PGP must
  1066. check that your own key has not been tampered with.  To do this, PGP
  1067. must compare your public key against a backup copy of your secret key
  1068. on some tamper-resistant media, such as a write-protected floppy
  1069. disk.  A secret key contains all the information that your public key
  1070. has, plus some secret components.  This means PGP can check your
  1071. public key against a backup copy of your secret key.
  1072.  
  1073. The configuration parameter BAKRING specifies what pathname to use
  1074. for PGP's trusted backup copy of your secret key ring.  On MSDOS, you
  1075. could set it to "a:\secring.pgp" to point it at a write-protected
  1076. backup copy of your secret key ring on your floppy drive.  This check
  1077. is performed only when you execute the PGP -kc option to check your
  1078. whole public key ring.
  1079.  
  1080. If BAKRING is not defined, PGP will not check your own key against
  1081. any backup copy.
  1082.  
  1083. For further details, see the sections "How to Protect Public Keys
  1084. from Tampering" and "How Does PGP Keep Track of Which Keys are
  1085. Valid?" in the Essential Topics volume.
  1086.  
  1087.  
  1088. PUBRING - Filename for Your Public Keyring
  1089. ------------------------------------------
  1090.  
  1091. Default setting:  PUBRING = "$PGPPATH/pubring.pgp"
  1092.  
  1093. You may want to keep your public keyring in a directory separate from
  1094. your PGP configuration file in the directory specified by your
  1095. $PGPPATH environmental variable.  You may specify the full path and
  1096. filename for your public keyring by setting the PUBRING parameter. 
  1097. For example, on an MSDOS system, you might want to keep your public
  1098. keyring on a floppy disk by:
  1099.  
  1100.    PUBRING = "a:pubring.pgp"
  1101.  
  1102. This feature is especially handy for specifying an alternative
  1103. keyring on the command line.
  1104.  
  1105.  
  1106. SECRING - Filename for Your Secret Keyring
  1107. ------------------------------------------
  1108.  
  1109. Default setting:  SECRING = "$PGPPATH/secring.pgp"
  1110.  
  1111. You may want to keep your secret keyring in a directory separate from
  1112. your PGP configuration file in the directory specified by your
  1113. $PGPPATH environmental variable.  This comes in handy for putting
  1114. your secret keyring in a directory or device that is more protected
  1115. than your public keyring.  You may specify the full path and filename
  1116. for your secret keyring by setting the SECRING parameter.  For
  1117. example, on an MSDOS system, you might want to keep your secret
  1118. keyring on a floppy disk by:
  1119.  
  1120.    SECRING = "a:secring.pgp"
  1121.  
  1122.  
  1123. RANDSEED - Filename for Random Number Seed
  1124. ------------------------------------------
  1125.  
  1126. Default setting:  RANDSEED = "$PGPPATH/randseed.bin"
  1127.  
  1128. You may want to keep your random number seed file (for generation of
  1129. session keys) in a directory separate from your PGP configuration file
  1130. in the directory specified by your $PGPPATH environmental variable. 
  1131. This comes in handy for putting your random number seed file in a
  1132. directory or device that is more protected than your public keyring. 
  1133. You may specify the full path and filename for your random seed file
  1134. by setting the RANDSEED parameter.  For example, on an MSDOS system,
  1135. you might want to keep it on a floppy disk by:
  1136.  
  1137.    RANDSEED = "a:randseed.bin"
  1138.  
  1139.  
  1140. PAGER - Selects Shell Command to Display Plaintext Output
  1141. ---------------------------------------------------------
  1142.  
  1143. Default setting:  PAGER = ""
  1144.  
  1145. PGP lets you view the decrypted plaintext output on your screen (like
  1146. the Unix-style "more" command), without writing it to a file, if you
  1147. use the -m (more) option while decrypting.  This displays the
  1148. decrypted plaintext display on your screen one screenful at a time.
  1149.  
  1150. If you prefer to use a fancier page display utility, rather than
  1151. PGP's built-in one, you can specify the name of a shell command that
  1152. PGP will invoke to display your plaintext output file.  The
  1153. configuration parameter PAGER specifies the shell command to invoke
  1154. to display the file.  For example, on MSDOS systems, you might want
  1155. to use the popular shareware program "list.com" to display your
  1156. plaintext message.  Assuming you have a copy of "list.com", you may 
  1157. set PAGER accordingly:
  1158.  
  1159.    PAGER = "list"
  1160.  
  1161. However, if the sender specified that this file is for your eyes
  1162. only, and may not be written to disk, PGP always uses its own
  1163. built-in display function.
  1164.  
  1165. For further details, see the section "Displaying Decrypted Plaintext 
  1166. on Your Screen".
  1167.  
  1168.  
  1169. SHOWPASS - Echo Pass Phrase to User
  1170. -----------------------------------
  1171.  
  1172. Default setting:  SHOWPASS = off
  1173.  
  1174. Normally, PGP does not let you see your pass phrase as you type it
  1175. in.  This makes it harder for someone to look over your shoulder
  1176. while you type and learn your pass phrase.  But some typing-impaired
  1177. people have problems typing their pass phrase without seeing what
  1178. they are typing, and they may be typing in the privacy of their own
  1179. homes.  So they asked if PGP can be configured to let them see what
  1180. they type when they type in their pass phrase.
  1181.  
  1182. The configuration parameter SHOWPASS enables PGP to echo your typing 
  1183. during pass phrase entry.
  1184.  
  1185.  
  1186. TZFIX - Timezone Adjustment
  1187. ---------------------------
  1188.  
  1189. Default setting:  TZFIX = 0
  1190.  
  1191. PGP provides timestamps for keys and signature certificates in
  1192. Greenwich Mean Time (GMT), or Coordinated Universal Time (UTC), which
  1193. means the same thing for our purposes.  When PGP asks the system for
  1194. the time of day, the system is supposed to provide it in GMT.  
  1195.  
  1196. But sometimes, because of improperly configured MSDOS systems, the
  1197. system time is returned in US Pacific Standard Time time plus 8
  1198. hours.  Sounds weird, doesn't it?  Perhaps because of some sort of US
  1199. west-coast jingoism, MSDOS presumes local time is US Pacific time,
  1200. and pre-corrects Pacific time to GMT.  This adversely affects the
  1201. behavior of the internal MSDOS GMT time function that PGP calls. 
  1202. However, if your MSDOS environmental variable TZ is already properly
  1203. defined for your timezone, this corrects the misconception MSDOS has
  1204. that the whole world lives on the US west coast.  
  1205.  
  1206. The configuration parameter TZFIX specifies the number of hours to
  1207. add to the system time function to get GMT, for GMT timestamps on
  1208. keys and signatures.  If the MSDOS environmental variable TZ is
  1209. defined properly, you can leave TZFIX=0.  Unix systems usually
  1210. shouldn't need to worry about setting TZFIX at all.  But if you are
  1211. using some other obscure operating system that doesn't know about
  1212. GMT, you may have to use TZFIX to adjust the system time to GMT. 
  1213.  
  1214. On MSDOS systems that do not have TZ defined in the environment, you
  1215. should make TZFIX=0 for California, -1 for Colorado, -2 for Chicago,
  1216. -3 for New York, -8 for London, -9 for Amsterdam.  In the summer,
  1217. TZFIX should be manually decremented from these values.  What a mess.
  1218.  
  1219. It would be much cleaner to set your MSDOS environmental variable TZ
  1220. in your AUTOEXEC.BAT file, and not use the TZFIX correction.  Then
  1221. MSDOS gives you good GMT timestamps, and will handle daylight savings
  1222. time adjustments for you.  Here are some sample lines to insert into
  1223. AUTOEXEC.BAT, depending on your time zone:
  1224.  
  1225. For Los Angeles:    SET TZ=PST8PDT
  1226. For Denver:            SET TZ=MST7MDT
  1227. For Arizona:        SET TZ=MST7
  1228.     (Arizona never uses daylight savings time)
  1229. For Chicago:        SET TZ=CST6CDT
  1230. For New York:        SET TZ=EST5EDT
  1231. For London:            SET TZ=GMT0BST
  1232. For Amsterdam:        SET TZ=MET-1DST
  1233. For Moscow:            SET TZ=MSK-3MSD
  1234. For Aukland:        SET TZ=NZT-13
  1235.  
  1236.  
  1237. CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text
  1238. ------------------------------------------------------------------
  1239.  
  1240. Default setting:  CLEARSIG = on
  1241.  
  1242. Normally, unencrypted PGP signed messages have a signature
  1243. certificate prepended in binary form.  Also, the signed message is
  1244. compressed, rendering the message unreadable to casual human eyes,
  1245. even though the message is not actually encrypted.  To send this
  1246. binary data through a 7-bit E-mail channel, radix-64 ASCII armor is
  1247. applied (see the ARMOR parameter).  Even if PGP didn't compress the
  1248. message, the ASCII armor would still render the message unreadable to
  1249. human eyes.  The recipient must use PGP to strip the armor off and
  1250. decompress it before reading the message.
  1251.  
  1252. If the original plaintext message is in text (not binary) form, there
  1253. is a way to send a signed message through an E-mail channel in such a
  1254. way that the signed message is not compressed and the ASCII armor is
  1255. applied only to the binary signature certificate, but not to the
  1256. plaintext message.  The CLEARSIG flag provides this useful feature,
  1257. making it possible to generate a signed message that can be read with
  1258. human eyes, without the aid of PGP.  Of course, you still need PGP to
  1259. actually check the signature.
  1260.  
  1261. The CLEARSIG flag is preset to "on" beginning with PGP version 2.5. 
  1262. To enable the full CLEARSIG behavior, the ARMOR and TEXTMODE flags
  1263. must also be turned on.  Set ARMOR=ON (or use the -a option), and set
  1264. TEXTMODE=ON (or use the -t option).  If your config file has CLEARSIG
  1265. turned off, you can turn it back on again directly on the command
  1266. line, like so:
  1267.  
  1268.      pgp -sta +clearsig=on message.txt
  1269.  
  1270. This message representation is analogous to the MIC-CLEAR message type
  1271. used in Internet Privacy Enhanced Mail (PEM).  It is important to
  1272. note that since this method only applies ASCII armor to the binary
  1273. signature certificate, and not to the message text itself, there is
  1274. some risk that the unarmored message may suffer some accidental
  1275. molestation while en route.  This can happen if it passes through
  1276. some E-mail gateway that performs character set conversions, or in
  1277. some cases extra spaces may be added to or stripped from the ends of
  1278. lines.  If this occurs, the signature will fail to verify, which may
  1279. give a false indication of intentional tampering.  But since PEM
  1280. lives under a similar vulnerability, it seems worth having this
  1281. feature despite the risks.
  1282.  
  1283. Beginning with PGP version 2.2, trailing blanks are ignored on each
  1284. line in calculating the signature for text in CLEARSIG mode.
  1285.  
  1286.  
  1287. VERBOSE - Quiet, Normal, or Verbose Messages
  1288. --------------------------------------------
  1289.  
  1290. Default setting:  VERBOSE = 1
  1291.  
  1292. VERBOSE may be set to 0, 1, or 2, depending on how much detail you
  1293. want to see from PGP diagnostic messages.  The settings are:
  1294.  
  1295. 0 - Display messages only if there is a problem.  Unix fans wanted
  1296. this "quiet mode" setting.
  1297.  
  1298. 1 - Normal default setting.  Displays a reasonable amount of detail
  1299. in diagnostic or advisory messages.
  1300.  
  1301. 2 - Displays maximum information, usually to help diagnose problems
  1302. in PGP.  Not recommended for normal use.  Besides, PGP doesn't have
  1303. any problems, right?
  1304.  
  1305.  
  1306. INTERACTIVE - Ask for Confirmation for Key Adds
  1307. -----------------------------------------------
  1308.  
  1309. Default Setting:  INTERACTIVE = off
  1310.  
  1311. Enabling this mode will mean that if you add a key file containing
  1312. multiple keys to your key ring, PGP will ask for confirmation for
  1313. each key before adding it to your key ring.
  1314.  
  1315.  
  1316. NOMANUAL - Let PGP Generate Keys Without the Manual
  1317. ---------------------------------------------------
  1318.  
  1319. Default Setting:  NOMANUAL = off
  1320.  
  1321. It is important that the freeware version of PGP not be distributed
  1322. without the user documentation, which normally comes with it in the
  1323. standard release package.  This manual contains important information
  1324. for using PGP, as well as important legal notices.  But some people
  1325. have distributed previous versions of PGP without the manual, causing
  1326. a lot of problems for a lot of people who get it.  To discourage the
  1327. distribution of PGP without the required documentation, PGP has been
  1328. changed to require the PGP User's Guide to be found somewhere on your
  1329. computer (like in your PGP directory) before PGP will let you generate
  1330. a key pair.  However, some users like to use PGP on tiny palmtop
  1331. computers with limited storage capacity, so they like to run PGP
  1332. without the documentation present on their systems.  To satisfy these
  1333. users, PGP can be made to relax its requirement that the manual be
  1334. present, by enabling the NOMANUAL flag on the command line during key
  1335. generation, like so:
  1336.  
  1337.     pgp -kg +nomanual
  1338.  
  1339. The NOMANUAL flag can only be set on the command line, not in the
  1340. config file.  Since you must read this manual to learn how to enable
  1341. this simple override feature, I hope this will still be effective in
  1342. discouraging the distribution of PGP without the manual.
  1343.  
  1344. Some people may object to PGP insisting on finding the manual
  1345. somewhere in the neighborhood to generate a key.  They bristle
  1346. against this seemingly authoritarian attitude.  Some people have even
  1347. modified PGP to defeat this feature, and redistributed their hotwired
  1348. version to others.  That creates problems for me.  Before I added
  1349. this feature, there were maimed versions of the PGP distribution
  1350. package floating around that lacked the manual.  One of them was
  1351. uploaded to Compuserve, and was distributed to countless users who
  1352. called me on the phone to ask me why such a complicated program had
  1353. no manual.  It spread out to BBS systems around the country.  And a
  1354. freeware distributor got hold of the package from Compuserve and
  1355. enshrined it on CD-ROM, distributing thousands of copies without the
  1356. manual.  What a mess.
  1357.  
  1358.  
  1359.  
  1360. A Peek Under the Hood
  1361. =====================
  1362.  
  1363. Let's take a look at a few internal features of PGP.
  1364.  
  1365.  
  1366. Random Numbers
  1367. --------------
  1368.  
  1369. PGP uses a cryptographically strong pseudorandom number generator for
  1370. creating temporary conventional session keys.  The seed file for this
  1371. is called  "randseed.bin".  It too can be kept in whatever directory
  1372. is indicated by the PGPPATH environmental variable.  If this random
  1373. seed file does not exist, it is automatically created and seeded with
  1374. truly random numbers derived from timing your keystroke latencies.  
  1375.  
  1376. This generator reseeds the disk file each time it is used by mixing
  1377. in new key material partially derived with the time of day and other
  1378. truly random sources.  It uses the conventional encryption algorithm
  1379. as an engine for the random number generator.  The seed file contains
  1380. both random seed material and random key material to key the
  1381. conventional encryption engine for the random generator.
  1382.  
  1383. This random seed file should be at least slightly protected from
  1384. disclosure, to reduce the risk of an attacker deriving your next or
  1385. previous session keys.  The attacker would have a very hard time
  1386. getting anything useful from capturing this random seed file, because
  1387. the file is cryptographically laundered before and after each use. 
  1388. Nonetheless, it seems prudent to at least try to keep it from falling
  1389. into the wrong hands.
  1390.  
  1391. If you feel uneasy about trusting any algorithmically derived random
  1392. number source however strong, keep in mind that you already trust the
  1393. strength of the same conventional cipher to protect your messages. 
  1394. If it's strong enough for that, then it should be strong enough to
  1395. use as a source of random numbers for temporary session keys.  Note
  1396. that PGP still uses truly random numbers from physical sources
  1397. (mainly keyboard timings) to generate long-term public/secret key
  1398. pairs.
  1399.  
  1400.  
  1401.  
  1402. PGP's Conventional Encryption Algorithm
  1403. ---------------------------------------
  1404.  
  1405. As described earlier, PGP "bootstraps" into a conventional single-key
  1406. encryption algorithm by using a public key algorithm to encipher the
  1407. conventional session key and then switching to fast conventional
  1408. cryptography.  So let's talk about this conventional encryption
  1409. algorithm.  It isn't the DES.
  1410.  
  1411. The Federal Data Encryption Standard (DES) used to be a good
  1412. algorithm for most commercial applications.  But the Government never
  1413. did trust the DES to protect its own classified data, because the DES
  1414. key length is only 56 bits, short enough for a brute force attack. 
  1415. Also, the full 16-round DES has been attacked with some success by
  1416. Biham and Shamir using differential cryptanalysis, and by Matsui
  1417. using linear cryptanalysis.
  1418.  
  1419. The most devastating practical attack on the DES was described at the
  1420. Crypto '93 conference, where Michael Wiener of Bell Northern Research
  1421. presented a paper on how to crack the DES with a special machine.  He
  1422. has fully designed and tested a chip that guesses 50 million DES keys
  1423. per second until it finds the right one.  Although he has refrained
  1424. from building the real chips so far, he can get these chips
  1425. manufactured for $10.50 each, and can build 57000 of them into a
  1426. special machine for $1 million that can try every DES key in 7 hours,
  1427. averaging a solution in 3.5 hours.  $1 million can be hidden in the
  1428. budget of many companies.  For $10 million, it takes 21 minutes to
  1429. crack, and for $100 million, just two minutes.  With any major
  1430. government's budget for examining DES traffic, it can be cracked in
  1431. seconds.  This means that straight 56-bit DES is now effectively dead
  1432. for purposes of serious data security applications.  
  1433.  
  1434. A possible successor to DES may be a variation known as "triple DES",
  1435. which uses two DES keys to encrypt three times, achieving an
  1436. effective key space of 112 bits.  But this approach is three times
  1437. slower than normal DES.  A future version of PGP may support triple
  1438. DES as an option.
  1439.  
  1440. PGP does not use the DES as its conventional single-key algorithm to
  1441. encrypt messages.  Instead, PGP uses a different conventional
  1442. single-key block encryption algorithm, called IDEA™.
  1443.  
  1444. For the cryptographically curious, the IDEA cipher has a 64-bit block
  1445. size for the plaintext and the ciphertext.  It uses a key size of 128
  1446. bits.  It is based on the design concept of "mixing operations from
  1447. different algebraic groups".  It runs much faster in software than
  1448. the DES.  Like the DES, it can be used in cipher feedback (CFB) and
  1449. cipher block chaining (CBC) modes.  PGP uses it in 64-bit CFB mode.
  1450.  
  1451. The IPES/IDEA block cipher was developed at ETH in Zurich by James L.
  1452. Massey and Xuejia Lai, and published in 1990.  This is not a 
  1453. "home-grown" algorithm.  Its designers have a distinguished
  1454. reputation in the cryptologic community.  Early published papers on
  1455. the algorithm called it IPES (Improved Proposed Encryption Standard),
  1456. but they later changed the name to IDEA (International Data
  1457. Encryption Algorithm).  So far, IDEA has resisted attack much better
  1458. than other ciphers such as FEAL, REDOC-II, LOKI, Snefru and Khafre. 
  1459. And recent evidence suggests that IDEA is more resistant than the DES
  1460. to Biham & Shamir's highly successful differential cryptanalysis
  1461. attack.  Biham and Shamir have been examining the IDEA cipher for
  1462. weaknesses, without success.  Academic cryptanalyst groups in
  1463. Belgium, England, and Germany are also attempting to attack it, as
  1464. well as the military services from several European countries.  As
  1465. this new cipher continues to attract attack efforts from the most
  1466. formidable quarters of the cryptanalytic world, confidence in IDEA is
  1467. growing with the passage of time.
  1468.  
  1469. Every once in a while, I get a letter from someone who has just
  1470. learned the awful truth that PGP does not use pure RSA to encrypt
  1471. bulk data.  They are concerned that the whole package is weakened if
  1472. we use a hybrid public-key and conventional scheme just to speed
  1473. things up.  After all, a chain is only as strong as its weakest
  1474. link.  They demand an explanation for this apparent "compromise" in
  1475. the strength of PGP.  This may be because they have been caught up in
  1476. the public's reverence and awe for the strength and mystique of RSA,
  1477. mistakenly believing that RSA is intrinsically stronger than any
  1478. conventional cipher.  Well, it's not.  
  1479.  
  1480. People who work in factoring research say that the workload to
  1481. exhaust all the possible 128-bit keys in the IDEA cipher would
  1482. roughly equal the factoring workload to crack a 3100-bit RSA key,
  1483. which is quite a bit bigger than the 1024-bit RSA key size that most
  1484. people use for high security applications.  Given this range of key
  1485. sizes, and assuming there are no hidden weaknesses in the
  1486. conventional cipher, the weak link in this hybrid approach is in the
  1487. public key algorithm, not the conventional cipher.
  1488.  
  1489. It is not ergonomically practical to use pure RSA with large keys to
  1490. encrypt and decrypt long messages.  A 1024-bit RSA key would decrypt
  1491. messages about 4000 times slower than the IDEA cipher.  Absolutely no
  1492. one does it that way in the real world.  Many people less experienced
  1493. in cryptography do not realize that the attraction of public key
  1494. cryptography is not because it is intrinsically stronger than a
  1495. conventional cipher-- its appeal is because it helps you manage keys
  1496. more conveniently.
  1497.  
  1498. Not only is RSA too slow to use on bulk data, but it even has certain
  1499. weaknesses that can be exploited in some special cases of particular
  1500. kinds of messages that are fed to the RSA cipher, even for large
  1501. keys.  These special cases can be avoided by using the hybrid
  1502. approach of using RSA to encrypt random session keys for a
  1503. conventional cipher, like PGP does.  So the bottom line is this: 
  1504. Using pure RSA on bulk data is the wrong approach, period.  It's too
  1505. slow, it's not stronger, and may even be weaker.  If you find a
  1506. software application that uses pure RSA on bulk data, it probably
  1507. means the implementor does not understand these issues, which could
  1508. imply he doesn't understand other important concepts of cryptography.
  1509.  
  1510.  
  1511.  
  1512. Data Compression
  1513. ----------------
  1514.  
  1515. PGP normally compresses the plaintext before encrypting it.  It's too
  1516. late to compress it after it has been encrypted; encrypted data is
  1517. incompressible.  Data compression saves modem transmission time and
  1518. disk space and more importantly strengthens cryptographic security.  
  1519. Most cryptanalysis techniques exploit redundancies found in the
  1520. plaintext to crack the cipher.  Data compression reduces this
  1521. redundancy in the plaintext, thereby greatly enhancing resistance to 
  1522. cryptanalysis.  It takes extra time to compress the plaintext, but 
  1523. from a security point of view it seems worth it, at least in my 
  1524. cautious opinion. 
  1525.  
  1526. Files that are too short to compress or just don't compress well are
  1527. not compressed by PGP.  
  1528.  
  1529. If you prefer, you can use PKZIP to compress the plaintext before
  1530. encrypting it.  PKZIP is a widely-available and effective MSDOS
  1531. shareware compression utility from PKWare, Inc.  Or you can use ZIP,
  1532. a PKZIP-compatible freeware compression utility on Unix and other
  1533. systems, available from Jean-Loup Gailly.  There is some advantage in
  1534. using PKZIP or ZIP in certain cases, because unlike PGP's built-in
  1535. compression algorithm, PKZIP and ZIP have the nice feature of
  1536. compressing multiple files into a single compressed file, which is
  1537. reconstituted again into separate files when decompressed.  PGP will
  1538. not try to compress a plaintext file that has already been
  1539. compressed.  After decrypting, the recipient can decompress the
  1540. plaintext with PKUNZIP.  If the decrypted plaintext is a PKZIP
  1541. compressed file, PGP automatically recognizes this and advises the 
  1542. recipient that the decrypted plaintext appears to be a PKZIP file.
  1543.  
  1544. For the technically curious readers, the current version of PGP uses
  1545. the freeware ZIP compression routines written by Jean-loup Gailly,
  1546. Mark Adler, and Richard B. Wales.  This ZIP software uses
  1547. functionally-equivalent compression algorithms as those used by
  1548. PKWare's new PKZIP 2.0.  This ZIP compression software was selected
  1549. for PGP mainly because of its free portable C source code
  1550. availability, and because it has a really good compression ratio, and
  1551. because it's fast.  
  1552.  
  1553. Peter Gutmann has also written a nice compression utility called
  1554. HPACK, available for free from many Internet FTP sites.  It encrypts
  1555. the compressed archives, using PGP data formats and key rings.  He
  1556. wanted me to mention that here.
  1557.  
  1558.  
  1559.  
  1560. Message Digests and Digital Signatures
  1561. --------------------------------------
  1562.  
  1563. To create a digital signature, PGP encrypts with your secret key. 
  1564. But PGP doesn't actually encrypt your entire message with your secret
  1565. key-- that would take too long.  Instead, PGP encrypts a "message
  1566. digest".  
  1567.  
  1568. The message digest is a compact (128 bit) "distillate" of your
  1569. message, similar in concept to a checksum.  You can also think of it
  1570. as a "fingerprint" of the message.  The message digest "represents"
  1571. your message, such that if the message were altered in any way, a
  1572. different message digest would be computed from it.  This makes it
  1573. possible to detect any changes made to the message by a forger.  A
  1574. message digest is computed using a cryptographically strong one-way
  1575. hash function of the message.  It would be computationally infeasible
  1576. for an attacker to devise a substitute message that would produce an
  1577. identical message digest.  In that respect, a message digest is much
  1578. better than a checksum, because it is easy to devise a different
  1579. message that would produce the same checksum.  But like a checksum,
  1580. you can't derive the original message from its message digest.  
  1581.  
  1582. A message digest alone is not enough to authenticate a message.  The
  1583. message digest algorithm is publicly known, and does not require
  1584. knowledge of any secret keys to calculate.  If all we did was attach
  1585. a message digest to a message, then a forger could alter a message
  1586. and simply attach a new message digest calculated from the new
  1587. altered message.  To provide real authentication, the sender has to
  1588. encrypt (sign) the message digest with his secret key.  
  1589.  
  1590. A message digest is calculated from the message by the sender.  The
  1591. sender's secret key is used to encrypt the message digest and an
  1592. electronic timestamp, forming a digital signature, or signature
  1593. certificate.  The sender sends the digital signature along with the
  1594. message.  The receiver receives the message and the digital
  1595. signature, and recovers the original message digest from the digital
  1596. signature by decrypting it with the sender's public key.  The
  1597. receiver computes a new message digest from the message, and checks
  1598. to see if it matches the one recovered from the digital signature.  If
  1599. it matches, then that proves the message was not altered, and it came
  1600. from the sender who owns the public key used to check the signature.
  1601.  
  1602. A potential forger would have to either produce an altered message
  1603. that produces an identical message digest (which is infeasible), or
  1604. he would have to create a new digital signature from a different
  1605. message digest (also infeasible, without knowing the true sender's
  1606. secret key).
  1607.  
  1608. Digital signatures prove who sent the message, and that the message
  1609. was not altered either by error or design.  It also provides
  1610. non-repudiation, which means the sender cannot easily disavow his
  1611. signature on the message.
  1612.  
  1613. Using message digests to form digital signatures has other advantages
  1614. besides being faster than directly signing the entire actual message
  1615. with the secret key.  Using message digests allows signatures to be
  1616. of a standard small fixed size, regardless of the size of the actual
  1617. message.  It also allows the software to check the message integrity
  1618. automatically, in a manner similar to using checksums.  And it allows
  1619. signatures to be stored separately from messages, perhaps even in a
  1620. public archive, without revealing sensitive information about the
  1621. actual messages, because no one can derive any message content from a
  1622. message digest.
  1623.  
  1624. The message digest algorithm used here is the MD5 Message Digest
  1625. Algorithm, placed in the public domain by RSA Data Security, Inc.
  1626. MD5's designer, Ronald Rivest, writes this about MD5:
  1627.  
  1628. "It is conjectured that the difficulty of coming up with two messages
  1629. having the same message digest is on the order of 2^64 operations,
  1630. and that the difficulty of coming up with any message having a given
  1631. message digest is on the order of 2^128 operations.  The MD5
  1632. algorithm has been carefully scrutinized for weaknesses.  It is,
  1633. however, a relatively new algorithm and further security analysis is
  1634. of course justified, as is the case with any new proposal of this
  1635. sort.  The level of security provided by MD5 should be sufficient for
  1636. implementing very high security hybrid digital signature schemes
  1637. based on MD5 and the RSA public-key cryptosystem."
  1638.  
  1639.  
  1640.  
  1641. Compatibility with Previous and Future Versions of PGP
  1642. ======================================================
  1643.  
  1644. PGP version 2.6 can read anything produced by versions 2.3 through
  1645. 2.7.  However, because of a negotiated agreement between MIT and RSA
  1646. Data Security, PGP 2.6 was programmed to change its behavior slightly
  1647. on 1 September 1994, triggered by a built-in software timer.  On that
  1648. date, version 2.6 started producing a new and slightly different data
  1649. format for messages, signatures and keys.  PGP 2.6 will still be able
  1650. to read and process messages, signatures, and keys produced under the
  1651. old format, but it will generate the new format.  This change is
  1652. intended to discourage people from continuing to use the older (2.3a
  1653. and earlier) versions of PGP, which Public Key Partners contends
  1654. infringes its RSA patent (see the section on Legal Issues).  ViaCrypt
  1655. PGP (see the section Where to Get a Commercial Version of PGP),
  1656. versions 2.4 and 2.7, avoids questions of infringement through
  1657. Viacrypt's license arrangement with Public Key Partners.  PGP 2.5 and
  1658. 2.6 avoid questions of infringement by using the RSAREF™
  1659. Cryptographic Toolkit, under license from RSA Data Security, Inc.
  1660.  
  1661. Outside the United States, the RSA patent is not in force, so PGP
  1662. users there are free to use implementations of PGP that do not rely
  1663. on RSAREF and its restrictions.  See the notes on foreign versions in
  1664. the Legal Issues section later in this manual.  It seems likely that
  1665. any versions of PGP prepared outside the US will accept the new
  1666. format, whose detailed description is available from MIT.  If
  1667. everyone upgrades before September 1994, or soon thereafter, there
  1668. will be little interoperability problems.
  1669.  
  1670. This format change beginning with 2.6 is similar to the process that
  1671. naturally happens when new features are added, causing older versions
  1672. of PGP to be unable to read stuff from the newer PGP, while the newer
  1673. version can still read the old stuff.  The only difference is that
  1674. this is a "legal upgrade", instead of a technical one.  It's a
  1675. worthwhile change, if it can achieve peace in our time.
  1676.  
  1677. According to ViaCrypt, which sells a commercial version of PGP,
  1678. ViaCrypt PGP will evolve to maintain interoperability with new
  1679. freeware versions of PGP.
  1680.  
  1681. There is a another change that effects interoperability with earlier
  1682. versions of PGP.  Unfortunately, due to data format limitations
  1683. imposed by RSAREF, PGP 2.5 and 2.6 cannot interpret any messages or
  1684. signatures made with PGP version 2.2 or earlier.  Since we had no
  1685. choice but to use the new data formats, because of the need to switch
  1686. to RSAREF, we can't do anything about this problem.
  1687.  
  1688. Beginning with version 2.4 (which was ViaCrypt's first version)
  1689. through at least 2.6, PGP does not allow you to generate RSA keys
  1690. bigger than 1024 bits.  The upper limit was always intended to be
  1691. 1024 bits -- there had to be some kind of upper limit, for
  1692. performance and interoperability reasons.  But because of a bug in
  1693. earlier versions of PGP, it was possible to generate keys larger than
  1694. 1024 bits.  These larger keys caused interoperability problems
  1695. between different older versions of PGP that used different
  1696. arithmetic algorithms with different native word sizes.  On some
  1697. platforms, PGP choked on the larger keys.  In addition to these older
  1698. key size problems, the 1024-bit limit is now enforced by RSAREF.  A
  1699. 1024-bit key is very likely to be well out of reach of attacks by
  1700. major governments.  In a future version, PGP will support bigger keys.
  1701.  
  1702. In general, there is compatibility from version 2.0 upwards through
  1703. 2.4.  Because new features are added, older versions may not always be
  1704. able to handle some files created with newer versions.  Because of
  1705. massive changes to all the algorithms and data structures, PGP version
  1706. 2.0 (and later) is not even slightly compatible with PGP version 1.0,
  1707. which no one uses anymore anyway.
  1708.  
  1709. Future versions of PGP may have to change the data formats for
  1710. messages, signatures, keys and key rings, in order to provide
  1711. important new features.  We will endeavor to make future versions
  1712. handle keys, signatures, and messages from this version, but this is
  1713. not guaranteed.  Future releases may provide conversion utilities to
  1714. convert old keys, but you may have to dispose of old messages created
  1715. with the old PGP.  Also, this current version may not be able to read
  1716. stuff produced from all future versions.  
  1717.  
  1718.  
  1719.  
  1720. Vulnerabilities
  1721. ===============
  1722.  
  1723. No data security system is impenetrable.  PGP can be circumvented in
  1724. a variety of ways.  In any data security system, you have to ask
  1725. yourself if the information you are trying to protect is more
  1726. valuable to your attacker than the cost of the attack.  This should
  1727. lead you to protecting yourself from the cheapest attacks, while not
  1728. worrying about the more expensive attacks.  
  1729.  
  1730. Some of the discussion that follows may seem unduly paranoid, but
  1731. such an attitude is appropriate for a reasonable discussion of
  1732. vulnerability issues. 
  1733.  
  1734.  
  1735. Compromised Pass Phrase and Secret Key
  1736. --------------------------------------
  1737.  
  1738. Probably the simplest attack is if you leave your pass phrase for
  1739. your secret key written down somewhere.  If someone gets it and also
  1740. gets your secret key file, they can read your messages and make
  1741. signatures in your name.  
  1742.  
  1743. Don't use obvious passwords that can be easily guessed, such as the
  1744. names of your kids or spouse.  If you make your pass phrase a single
  1745. word, it can be easily guessed by having a computer try all the words
  1746. in the dictionary until it finds your password.  That's why a pass
  1747. phrase is so much better than a password.  A more sophisticated
  1748. attacker may have his computer scan a book of famous quotations to
  1749. find your pass phrase.  An easy to remember but hard to guess pass
  1750. phrase can be easily constructed by some creatively nonsensical
  1751. sayings or very obscure literary quotes.  
  1752.  
  1753. For further details, see the section "How to Protect Secret Keys from
  1754. Disclosure" in the Essential Topics volume of the PGP User's Guide.
  1755.  
  1756.  
  1757. Public Key Tampering
  1758. --------------------
  1759.  
  1760. A major vulnerability exists if public keys are tampered with.  This
  1761. may be the most crucially important vulnerability of a public key
  1762. cryptosystem, in part because most novices don't immediately
  1763. recognize it.  The importance of this vulnerability, and appropriate
  1764. hygienic countermeasures, are detailed in the section "How to Protect
  1765. Public Keys from Tampering" in the Essential Topics volume.    
  1766.  
  1767. To summarize:  When you use someone's public key, make certain it has
  1768. not been tampered with.  A new public key from someone else should be
  1769. trusted only if you got it directly from its owner, or if it has been
  1770. signed by someone you trust.  Make sure no one else can tamper with
  1771. your own public key ring.  Maintain physical control of both your
  1772. public key ring and your secret key ring, preferably on your own
  1773. personal computer rather than on a remote timesharing system.  Keep a
  1774. backup copy of both key rings.
  1775.  
  1776.  
  1777. "Not Quite Deleted" Files
  1778. -------------------------
  1779.  
  1780. Another potential security problem is caused by how most operating
  1781. systems delete files.  When you encrypt a file and then delete the
  1782. original plaintext file, the operating system doesn't actually
  1783. physically erase the data.  It merely marks those disk blocks as
  1784. deleted, allowing the space to be reused later.  It's sort of like
  1785. discarding sensitive paper documents in the paper recycling bin
  1786. instead of the paper shredder.  The disk blocks still contain the
  1787. original sensitive data you wanted to erase, and will probably
  1788. eventually be overwritten by new data at some point in the future. 
  1789. If an attacker reads these deleted disk blocks soon after they have
  1790. been deallocated, he could recover your plaintext. 
  1791.  
  1792. In fact this could even happen accidentally, if for some reason
  1793. something went wrong with the disk and some files were accidentally
  1794. deleted or corrupted.  A disk recovery program may be run to recover
  1795. the damaged files, but this often means some previously deleted files
  1796. are resurrected along with everything else.  Your confidential files
  1797. that you thought were gone forever could then reappear and be
  1798. inspected by whomever is attempting to recover your damaged disk.  
  1799. Even while you are creating the original message with a word
  1800. processor or text editor, the editor may be creating multiple
  1801. temporary copies of your text on the disk, just because of its
  1802. internal workings.  These temporary copies of your text are deleted
  1803. by the word processor when it's done, but these sensitive fragments
  1804. are still on your disk somewhere.  
  1805.  
  1806. Let me tell you a true horror story.  I had a friend, married with
  1807. young children, who once had a brief and not very serious affair. 
  1808. She wrote a letter to her lover on her word processor, and deleted
  1809. the letter after she sent it.  Later, after the affair was over, the
  1810. floppy disk got damaged somehow and she had to recover it because it
  1811. contained other important documents.  She asked her husband to
  1812. salvage the disk, which seemed perfectly safe because she knew she
  1813. had deleted the incriminating letter.  Her husband ran a commercial
  1814. disk recovery software package to salvage the files.  It recovered
  1815. the files alright, including the deleted letter.  He read it, which 
  1816. set off a tragic chain of events.  
  1817.  
  1818. The only way to prevent the plaintext from reappearing is to somehow
  1819. cause the deleted plaintext files to be overwritten.  Unless you know
  1820. for sure that all the deleted disk blocks will soon be reused, you
  1821. must take positive steps to overwrite the plaintext file, and also
  1822. any fragments of it on the disk left by your word processor.  You can
  1823. overwrite the original plaintext file after encryption by using the
  1824. PGP -w (wipe) option.  You can take care of any fragments of the
  1825. plaintext left on the disk by using any of the disk utilities
  1826. available that can overwrite all of the unused blocks on a disk.  For
  1827. example, the Norton Utilities for MSDOS can do this.
  1828.  
  1829. Even if you overwrite the plaintext data on the disk, it may still be
  1830. possible for a resourceful and determined attacker to recover the
  1831. data.  Faint magnetic traces of the original data remain on the disk
  1832. after it has been overwritten.  Special sophisticated disk recovery
  1833. hardware can sometimes be used to recover the data.
  1834.  
  1835.  
  1836. Viruses and Trojan Horses
  1837. -------------------------
  1838.  
  1839. Another attack could involve a specially-tailored hostile computer
  1840. virus or worm that might infect PGP or your operating system.  This
  1841. hypothetical virus could be designed to capture your pass phrase or
  1842. secret key or deciphered messages, and covertly write the captured
  1843. information to a file or send it through a network to the virus's
  1844. owner.  Or it might alter PGP's behavior so that signatures are not
  1845. properly checked.  This attack is cheaper than cryptanalytic attacks.
  1846.  
  1847. Defending against this falls under the category of defending against
  1848. viral infection generally.  There are some moderately capable
  1849. anti-viral products commercially available, and there are hygienic
  1850. procedures to follow that can greatly reduce the chances of viral
  1851. infection.  A complete treatment of anti-viral and anti-worm
  1852. countermeasures is beyond the scope of this document.  PGP has no
  1853. defenses against viruses, and assumes your own personal computer is a
  1854. trustworthy execution environment.  If such a virus or worm actually
  1855. appeared, hopefully word would soon get around warning everyone.  
  1856.  
  1857. Another similar attack involves someone creating a clever imitation
  1858. of PGP that behaves like PGP in most respects, but doesn't work the
  1859. way it's supposed to.  For example, it might be deliberately crippled
  1860. to not check signatures properly, allowing bogus key certificates to
  1861. be accepted.  This "Trojan horse" version of PGP is not hard for an
  1862. attacker to create, because PGP source code is widely available, so
  1863. anyone could modify the source code and produce a lobotomized zombie
  1864. imitation PGP that looks real but does the bidding of its diabolical
  1865. master.  This Trojan horse version of PGP could then be widely
  1866. circulated, claiming to be from me.  How insidious.
  1867.  
  1868. You should make an effort to get your copy of PGP from a reliable
  1869. source, whatever that means.  Or perhaps from more than one
  1870. independent source, and compare them with a file comparison utility.
  1871.  
  1872. There are other ways to check PGP for tampering, using digital
  1873. signatures.  If someone you trust signs the executable version of
  1874. PGP, vouching for the fact that it has not been infected or tampered
  1875. with, you can be reasonably sure that you have a good copy.  You
  1876. could use an earlier trusted version of PGP to check the signature on
  1877. a later suspect version of PGP.  But this will not help at all if
  1878. your operating system is infected, nor will it detect if your
  1879. original copy of PGP.EXE has been maliciously altered in such a way
  1880. as to compromise its own ability to check signatures.  This test also
  1881. assumes that you have a good trusted copy of the public key that you
  1882. use to check the signature on the PGP executable.
  1883.  
  1884. I recommend you not trust your copy of PGP unless it was originally
  1885. distributed by MIT or ViaCrypt, or unless it comes with a digitally
  1886. signed endorsement from me.  Every new version comes with one or more
  1887. digital signatures in the distribution package, signed by the
  1888. originator of that release package.  This is usually someone
  1889. representing MIT or ViaCrypt, or whoever released that version. 
  1890. Check the signatures on the version that you get.  I have actually
  1891. seen several bogus versions of PGP distribution packages, even from
  1892. apparantly reliable freeware distribution channels such as CD-ROM
  1893. distributors and Compuserve.  Always check the signature when you get
  1894. a new version.
  1895.  
  1896.  
  1897. Physical Security Breach
  1898. ------------------------
  1899.  
  1900. A physical security breach may allow someone to physically acquire
  1901. your plaintext files or printed messages.  A determined opponent
  1902. might accomplish this through burglary, trash-picking, unreasonable
  1903. search and seizure, or bribery, blackmail or infiltration of your
  1904. staff.  Some of these attacks may be especially feasible against
  1905. grassroots political organizations that depend on a largely volunteer
  1906. staff.  It has been widely reported in the press that the FBI's
  1907. COINTELPRO program used burglary, infiltration, and illegal bugging
  1908. against antiwar and civil rights groups.  And look what happened at
  1909. the Watergate Hotel.  
  1910.  
  1911. Don't be lulled into a false sense of security just because you have
  1912. a cryptographic tool.  Cryptographic techniques protect data only
  1913. while it's encrypted-- direct physical security violations can still
  1914. compromise plaintext data or written or spoken information.  
  1915.  
  1916. This kind of attack is cheaper than cryptanalytic attacks on PGP.
  1917.  
  1918.  
  1919. Tempest Attacks
  1920. ---------------
  1921.  
  1922. Another kind of attack that has been used by well-equipped opponents
  1923. involves the remote detection of the electromagnetic signals from
  1924. your computer.  This expensive and somewhat labor-intensive attack is
  1925. probably still cheaper than direct cryptanalytic attacks.  An
  1926. appropriately instrumented van can park near your office and remotely
  1927. pick up all of your keystrokes and messages displayed on your
  1928. computer video screen.  This would compromise all of your passwords,
  1929. messages, etc.  This attack can be thwarted by properly shielding all
  1930. of your computer equipment and network cabling so that it does not
  1931. emit these signals.  This shielding technology is known as "Tempest",
  1932. and is used by some Government agencies and defense contractors.  
  1933. There are hardware vendors who supply Tempest shielding commercially,
  1934. although it may be subject to some kind of Government licensing.  Now
  1935. why do you suppose the Government would restrict access to Tempest
  1936. shielding?
  1937.  
  1938.  
  1939. Exposure on Multi-user Systems
  1940. ------------------------------
  1941.  
  1942. PGP was originally designed for a single-user MSDOS machine under
  1943. your direct physical control.  I run PGP at home on my own PC, and
  1944. unless someone breaks into my house or monitors my electromagnetic
  1945. emissions, they probably can't see my plaintext files or secret keys. 
  1946.  
  1947. But now PGP also runs on multi-user systems such as Unix and VAX/VMS.
  1948. On multi-user systems, there are much greater risks of your plaintext
  1949. or keys or passwords being exposed.  The Unix system administrator or
  1950. a clever intruder can read your plaintext files, or perhaps even use
  1951. special software to covertly monitor your keystrokes or read what's
  1952. on your screen.  On a Unix system, any other user can read your
  1953. environment information remotely by simply using the Unix "ps"
  1954. command.  Similar problems exist for MSDOS machines connected on a
  1955. local area network.  The actual security risk is dependent on your
  1956. particular situation.  Some multi-user systems may be safe because
  1957. all the users are trusted, or because they have system security
  1958. measures that are safe enough to withstand the attacks available to
  1959. the intruders, or because there just aren't any sufficiently
  1960. interested intruders.  Some Unix systems are safe because they are
  1961. only used by one user-- there are even some notebook computers
  1962. running Unix.  It would be unreasonable to simply exclude PGP from
  1963. running on all Unix systems.
  1964.  
  1965. PGP is not designed to protect your data while it is in plaintext
  1966. form on a compromised system.  Nor can it prevent an intruder from
  1967. using sophisticated measures to read your secret key while it is
  1968. being used.  You will just have to recognize these risks on
  1969. multi-user systems, and adjust your expectations and behavior
  1970. accordingly.  Perhaps your situation is such that you should consider
  1971. running PGP only on an isolated single-user system under your direct
  1972. physical control.  That's what I do, and that's what I recommend.
  1973.  
  1974.  
  1975. Traffic Analysis
  1976. ----------------
  1977.  
  1978. Even if the attacker cannot read the contents of your encrypted
  1979. messages, he may be able to infer at least some useful information by
  1980. observing where the messages come from and where they are going, the
  1981. size of the messages, and the time of day the messages are sent. 
  1982. This is analogous to the attacker looking at your long distance phone
  1983. bill to see who you called and when and for how long, even though the
  1984. actual content of your calls is unknown to the attacker.  This is
  1985. called traffic analysis.  PGP alone does not protect against traffic
  1986. analysis.  Solving this problem would require specialized 
  1987. communication protocols designed to reduce exposure to traffic
  1988. analysis in your communication environment, possibly with some
  1989. cryptographic assistance.
  1990.  
  1991.  
  1992. Protecting Against Bogus Timestamps
  1993. -----------------------------------
  1994.  
  1995. A somewhat obscure vulnerability of PGP involves dishonest users
  1996. creating bogus timestamps on their own public key certificates and
  1997. signatures.  You can skip over this section if you are a casual user
  1998. and aren't deeply into obscure public key protocols.
  1999.  
  2000. There's nothing to stop a dishonest user from altering the date and
  2001. time setting of his own system's clock, and generating his own public
  2002. key certificates and signatures that appear to have been created at a
  2003. different time.  He can make it appear that he signed something
  2004. earlier or later than he actually did, or that his public/secret key
  2005. pair was created earlier or later.  This may have some legal or
  2006. financial benefit to him, for example by creating some kind of 
  2007. loophole that might allow him to repudiate a signature.
  2008.  
  2009. I think this problem of falsified timestamps in digital signatures is
  2010. no worse than it is already in handwritten signatures.  Anyone may
  2011. write a date next to their handwritten signature on a contract with
  2012. any date they choose, yet no one seems to be alarmed over this state
  2013. of affairs.  In some cases, an "incorrect" date on a handwritten
  2014. signature might not be associated with actual fraud.  The timestamp
  2015. might be when the signator asserts that he signed a document, or
  2016. maybe when he wants the signature to go into effect.
  2017.  
  2018. In situations where it is critical that a signature be trusted to
  2019. have the actual correct date, people can simply use notaries to
  2020. witness and date a handwritten signature.  The analog to this in
  2021. digital signatures is to get a trusted third party to sign a
  2022. signature certificate, applying a trusted timestamp.  No exotic or
  2023. overly formal protocols are needed for this.  Witnessed signatures
  2024. have long been recognized as a legitimate way of determining when a
  2025. document was signed.
  2026.  
  2027. A trustworthy Certifying Authority or notary could create notarized
  2028. signatures with a trustworthy timestamp.  This would not necessarily
  2029. require a centralized authority.  Perhaps any trusted introducer or
  2030. disinterested party could serve this function, the same way real
  2031. notary publics do now.  When a notary signs other people's
  2032. signatures, it creates a signature certificate of a signature
  2033. certificate.  This would serve as a witness to the signature the same
  2034. way real notaries now witness handwritten signatures.  The notary
  2035. could enter the detached signature certificate (without the actual
  2036. whole document that was signed) into a special log controlled by the
  2037. notary.  Anyone can read this log.  The notary's signature would have
  2038. a trusted timestamp, which might have greater credibility or more
  2039. legal significance than the timestamp in the original signature.
  2040.  
  2041. There is a good treatment of this topic in Denning's 1983 article in
  2042. IEEE Computer (see references).  Future enhancements to PGP might
  2043. have features to easily manage notarized signatures of signatures,
  2044. with trusted timestamps.
  2045.  
  2046.  
  2047. Cryptanalysis
  2048. -------------
  2049.  
  2050. An expensive and formidable cryptanalytic attack could possibly be
  2051. mounted by someone with vast supercomputer resources, such as a
  2052. Government intelligence agency.  They might crack your RSA key by
  2053. using some new secret factoring breakthrough.  Perhaps so, but it is
  2054. noteworthy that the US Government trusts the RSA algorithm enough in
  2055. some cases to use it to protect its own nuclear weapons, according to
  2056. Ron Rivest.  And civilian academia has been intensively attacking it
  2057. without success since 1978. 
  2058.  
  2059. Perhaps the Government has some classified methods of cracking the
  2060. IDEA™ conventional encryption algorithm used in PGP.  This is
  2061. every cryptographer's worst nightmare.  There can be no absolute
  2062. security guarantees in practical cryptographic implementations.  
  2063.  
  2064. Still, some optimism seems justified.  The IDEA algorithm's designers
  2065. are among the best cryptographers in Europe.  It has had extensive
  2066. security analysis and peer review from some of the best cryptanalysts
  2067. in the unclassified world.  It appears to have some design advantages
  2068. over the DES in withstanding differential and linear cryptanalysis,
  2069. which have both been used to crack the DES.  
  2070.  
  2071. Besides, even if this algorithm has some subtle unknown weaknesses,
  2072. PGP compresses the plaintext before encryption, which should greatly
  2073. reduce those weaknesses.  The computational workload to crack it is
  2074. likely to be much more expensive than the value of the message.
  2075.  
  2076. If your situation justifies worrying about very formidable attacks of
  2077. this caliber, then perhaps you should contact a data security
  2078. consultant for some customized data security approaches tailored to
  2079. your special needs.  Boulder Software Engineering, whose address and
  2080. phone are given at the end of this document, can provide such
  2081. services.
  2082.  
  2083.  
  2084. In summary, without good cryptographic protection of your data
  2085. communications, it may have been practically effortless and perhaps
  2086. even routine for an opponent to intercept your messages, especially
  2087. those sent through a modem or E-mail system.  If you use PGP and
  2088. follow reasonable precautions, the attacker will have to expend far
  2089. more effort and expense to violate your privacy. 
  2090.  
  2091. If you protect yourself against the simplest attacks, and you feel
  2092. confident that your privacy is not going to be violated by a
  2093. determined and highly resourceful attacker, then you'll probably be
  2094. safe using PGP.  PGP gives you Pretty Good Privacy.
  2095.  
  2096.  
  2097.  
  2098. Legal Issues
  2099. ============
  2100.  
  2101.  
  2102. Trademarks, Copyrights, and Warranties
  2103. --------------------------------------
  2104.  
  2105. "PGP", "Pretty Good Privacy", "Phil's Pretty Good Software", and the
  2106. "Pretty Good" label for computer software and hardware products are
  2107. all trademarks of Philip R. Zimmermann.
  2108.  
  2109. PGP is © Copyright Philip R. Zimmermann, 1990-1994.  All rights
  2110. reserved.  The PGP User's Guide is also copyright Philip Zimmermann,
  2111. 1990-1994.  All rights reserved.  These rights include but are not
  2112. limited to any foreign language translations of the manual or the
  2113. software, and all derivative works of both.
  2114.  
  2115. MIT may have a copyright on the particular software distribution
  2116. package that they distribute from the MIT FTP site.  This copyright
  2117. on the "compilation" of the distribution package in no way implies
  2118. that MIT has a copyright on PGP itself, or its user documentation. 
  2119.  
  2120. The author assumes no liability for damages resulting from the use of
  2121. this software, even if the damage results from defects in this
  2122. software, and makes no representations concerning the merchantability
  2123. of this software or its suitability for any specific purpose.  It is
  2124. provided "as is" without express or implied warranty of any kind. 
  2125. Because certain actions may delete files or render them
  2126. unrecoverable, the author assumes no responsibility for the loss or
  2127. modification of any data.
  2128.  
  2129.  
  2130.  
  2131. Patent Rights on the Algorithms
  2132. -------------------------------
  2133.  
  2134. The RSA public key cryptosystem was developed at MIT, which holds a
  2135. patent on it (U.S. patent #4,405,829, issued 20 Sep 1983).  A company
  2136. in California called Public Key Partners (PKP) holds the exclusive
  2137. commercial license to sell and sub-license the RSA public key
  2138. cryptosystem.  MIT distributes a freeware version of PGP under the
  2139. terms of the RSAREF license from RSA Data Security, Inc. (RSADSI).
  2140.  
  2141. At the time of this writing (September 1994), it appears that PKP may
  2142. be breaking up soon, in which case the patents they hold may fall
  2143. into other hands.  The RSA patent may end up with RSADSI.
  2144.  
  2145. Non-US users of earlier versions of PGP should note that the RSA
  2146. patent does not apply outside the US, and at least at the time of
  2147. this writing, the author is not aware of any RSA patent in any other
  2148. country.  Federal agencies may use the RSA algorithm, because the
  2149. Government paid for the development of RSA with grants from the
  2150. National Science Foundation and the Navy.  But despite the fact of
  2151. Government users having free access to the RSA algorithm, Government
  2152. use of PGP has additional restrictions imposed by the agreement I
  2153. have with ViaCrypt, as explained later.
  2154.  
  2155. I wrote my PGP software from scratch, with my own independently
  2156. developed implementation of the RSA algorithm.  Before publishing PGP
  2157. in 1991, I got a formal written legal opinion from a patent attorney
  2158. with extensive experience in software patents.  I'm convinced that
  2159. publishing PGP the way I did does not violate patent law.
  2160.  
  2161. Not only did PKP acquire the exclusive patent rights for the RSA
  2162. cryptosystem, but they also acquired the exclusive rights to three
  2163. other patents covering other public key schemes invented by others at
  2164. Stanford University, also developed with federal funding.  This
  2165. one company claims to have a legal lock in the USA on nearly all
  2166. practical public key cryptosystems.  They even appear to be claiming
  2167. patent rights on the very concept of public key cryptography,
  2168. regardless of what clever new original algorithms are independently
  2169. invented by others.  I find such a comprehensive monopoly troubling,
  2170. because I think public key cryptography is destined to become a
  2171. crucial technology in the protection of our civil liberties and
  2172. privacy in our increasingly connected society.  At the very least,
  2173. it places these vital tools at risk by affording to the Government
  2174. a single pressure point of influence.
  2175.  
  2176. Beginning with PGP version 2.5 (distributed by MIT, the holders of
  2177. the original RSA patent), the freeware version of PGP uses the RSAREF
  2178. subroutine library to perform its RSA calculations, under the RSAREF
  2179. license, which allows noncommercial use in the USA.  RSAREF is a
  2180. subroutine package from RSA Data Security Inc, that implements the
  2181. RSA algorithm.  The RSAREF subroutines are used instead of PGP's
  2182. original subroutines to implement the RSA functions in PGP.  See the
  2183. RSAREF license for terms and conditions of use of RSAREF
  2184. applications.
  2185.  
  2186. PGP 2.5 was released by MIT for a brief test period in May, 1994
  2187. before releasing 2.6.  PGP 2.5 was released under the 16 March, 1994
  2188. RSAREF license, which is a perpetual license, so it may legally be
  2189. used forever in the US.  But it would be better for PGP's legal and
  2190. political future for users in the United States to upgrade to version
  2191. 2.6 or later to facilitate the demise of PGP 2.3a and earlier
  2192. versions.  Also, PGP 2.5 has bugs that are corrected in 2.6, and 2.5
  2193. will not read the new data format after September 1, 1994.  (See the
  2194. section on Compatibility with Previous and Future Versions of PGP.)
  2195.  
  2196. The PGP 2.0 release was a joint effort of an international team of
  2197. software engineers, implementing enhancements to the original PGP
  2198. with design guidance from me.  It was released by Branko Lankester in
  2199. The Netherlands and Peter Gutmann in New Zealand, out of reach of US
  2200. patent law.  Although released only in Europe and New Zealand, it
  2201. spontaneously spread to the USA without help from me or the PGP
  2202. development team.
  2203.  
  2204. The IDEA™ conventional block cipher used by PGP is covered by a
  2205. patent in Europe, held by ETH and a Swiss company called Ascom-Tech
  2206. AG.  The US Patent number is 5,214,703, and the European patent
  2207. number is EP 0 482 154 B1.  IDEA™ is a trademark of Ascom-Tech AG.
  2208. There is no license fee required for noncommercial use of IDEA.
  2209. Commercial users of IDEA may obtain licensing details from Dieter
  2210. Profos, Ascom Tech AG, Teleservices Section, Postfach 151, 4502
  2211. Solothurn, Switzerland, Tel +41 65 242885, Fax +41 65 235761.   
  2212.  
  2213. Ascom-Tech AG has granted permission for the freeware version PGP to
  2214. use the IDEA cipher in non-commercial uses, everywhere.  In the US
  2215. and Canada, all commercial or Government users must obtain a licensed
  2216. version from ViaCrypt, who has a license from Ascom-Tech for the IDEA
  2217. cipher.  
  2218.  
  2219. Ascom-Tech has recently been changing its policies regarding the use
  2220. of IDEA in PGP for commercial use outside the US, and that policy
  2221. still seems to be in flux.  They tell me that their current thinking
  2222. is as follows:  They will allow commercial users of PGP outside the
  2223. US or Canada to use IDEA in PGP without paying royalties to
  2224. Ascom-Tech, because it is not currently possible for commercial users
  2225. to buy a licensed version of PGP outside the US or Canada.  If the
  2226. legal situation in the USA changes in the future, so that users
  2227. outside the US or Canada can buy a licensed version of PGP (either
  2228. from ViaCrypt, or from me, or from a foreign enterprise licensed by
  2229. me), then Ascom-Tech will begin enforcing its patent licensing
  2230. policies on commercial users who are in a position to buy a licensed
  2231. version of PGP.  To get a more up-to-date report on this, contact
  2232. Ascom-Tech AG.
  2233.  
  2234. The ZIP compression routines in PGP come from freeware source code,
  2235. with the author's permission.  I'm not aware of any patents on the
  2236. compression algorithms used in the ZIP routines.
  2237.  
  2238.  
  2239. Freeware Status and Restrictions
  2240. --------------------------------
  2241.  
  2242. PGP is not shareware, it's freeware.  Published as a community
  2243. service.  Giving PGP away for free will encourage far more people to
  2244. use it, which will have a greater social impact.  Feel free to
  2245. disseminate the complete unmodified PGP release package as widely as
  2246. possible, but be careful not to violate U.S. export controls if you
  2247. live in the USA.  Give it to all your friends.  If you have access to
  2248. any electronic Bulletin Board Systems, please upload the complete PGP
  2249. executable object release package to as many BBS's as possible.
  2250.  
  2251. You may also disseminate the source code release package.  PGP's
  2252. source code is published to assist public scrutiny of PGP to show that
  2253. it has no hidden weaknesses or back doors, and to help people to find
  2254. bugs and report them.  Recompile it and port it to new target
  2255. machines.  Experiment with the code and learn from it.
  2256.  
  2257. I place no restraints on your modifying the source code for your own
  2258. use.  However, do not distribute a modified version of PGP under the
  2259. name "PGP" without first getting permission from me.  Please respect
  2260. this restriction.  PGP's reputation for cryptographic integrity
  2261. depends on maintaining strict quality control on PGP's cryptographic
  2262. algorithms and protocols.  Beyond that, ad hoc "improvements" to PGP
  2263. can affect interoperability, which creates user confusion and
  2264. compatability problems that could damage PGP's (and my own)
  2265. reputation and undermine the good will earned by the PGP trademark.
  2266.  
  2267. This has already started to happen, which is why I'm making a point
  2268. of it here.  This creates technical support headaches, and I get
  2269. phone calls from confused users who run into problems either because
  2270. they have a mutant strain of PGP, or are trying to process a key,
  2271. signature, or message that came from an incompatible mutant strain of
  2272. PGP.  The source code to PGP was not published to help spawn these
  2273. mutant strains.
  2274.  
  2275. If you want to distribute a modified version of PGP, or use a modified
  2276. version to send messages to other people, you should name the program
  2277. in such a way that no one could mistake it for PGP.  The messages,
  2278. signatures, and keys it produces must also be labeled in such a way
  2279. that no one could mistake them for material produced by PGP.  If you
  2280. feel you must modify your copy of PGP, and there is any chance that
  2281. the modified version could escape into the environment, please contact
  2282. me first to discuss some easy methods for how to prevent people from
  2283. confusing your version with the standard PGP.  Perhaps we'll even
  2284. decide that your changes are appropriate for incorporating into the
  2285. standard PGP release.
  2286.  
  2287. Also, you should note that official executable versions of PGP are
  2288. always released signed by the PGP developers, so you can verify their
  2289. authenticity.  If you find a corrupted copy of PGP, or notice one
  2290. being distributed, please contact the people doing the distribution
  2291. and suggest that they replace this with an authentic version.
  2292.  
  2293. Some older versions of PGP were published under the terms of the
  2294. General Public License (GPL), a license designed by the Free Software
  2295. Foundation to protect the status of free software.  Newer freeware
  2296. versions of PGP are no longer published under the GPL.  The RSAREF
  2297. licensing terms are more stringent than those of the GPL.  But even
  2298. if a version of PGP is published without RSAREF, in a situation or
  2299. place where the RSA patent does not apply, I still do not want the
  2300. GPL to apply to PGP, for a variety of reasons, not the least of which
  2301. is because the GPL is not optimal for protecting PGP from being
  2302. republished with ad-hoc "improvements".
  2303.  
  2304. Outside the United States, the RSA patent is not in force, so PGP
  2305. users there are free to use implementations of PGP that do not rely
  2306. on RSAREF and its restrictions.  Canadians may use PGP without using
  2307. RSAREF, and there are legal ways to export PGP to Canada.  In Canada,
  2308. where RSAREF is not needed, it is easy to modify and recompile the
  2309. current PGP source code to perform the RSA calculations without using
  2310. the RSAREF library, just as it was done in PGP 2.3a.  In such a case,
  2311. this modified PGP may be re-released under the identical licensing
  2312. terms as the current official freeware PGP release, but without the
  2313. RSAREF-specific restrictions.  It may not be re-released under the
  2314. GPL, as certain older versions were.  And this manual must accompany
  2315. it.  That modified version of PGP may not be used in environments
  2316. where RSAREF would be needed.
  2317.  
  2318.  
  2319. Restrictions on Commercial Use of PGP
  2320. -------------------------------------
  2321.  
  2322. The freeware version of PGP is for personal, non-commercial use.  For
  2323. commercial use in the USA or Canada, contact ViaCrypt in Phoenix,
  2324. Arizona (phone 602 944-0773, or email viacrypt@acm.org).
  2325.  
  2326. I made an agreement with ViaCrypt in the summer of 1993 to license the
  2327. exclusive commercial rights to PGP, so that there would be a way for
  2328. corporations to use PGP without risk of a patent infringement lawsuit
  2329. from PKP.  For PGP to succeed in the long term as a viable industry
  2330. standard, the legal stigma associated with the RSA patent rights had
  2331. to be resolved.  ViaCrypt had already obtained a patent license from
  2332. PKP to make, use, and sell products that practice the RSA patents.
  2333. ViaCrypt offered a way out of the patent quagmire for PGP to penetrate
  2334. the corporate environment.  They could sell a fully-licensed version
  2335. of PGP, but only if I licensed it to them under these terms.  So we
  2336. entered into an agreement to do that, opening the door for PGP's
  2337. future in the commercial sector, which was necessary for PGP's
  2338. long-term political future.
  2339.  
  2340. Therefore, regardless of the complexities and partially overlapping
  2341. restrictions from all the other terms and conditions imposed by the
  2342. various patent and copyright licenses (RSA, RSAREF, and IDEA) from
  2343. various third parties, an additional overriding restriction on PGP
  2344. usage is imposed by my own agreement with ViaCrypt: The freeware
  2345. version of PGP is only for personal, non-commercial use -- all other
  2346. users in the USA and Canada must obtain a fully licensed version of
  2347. PGP from ViaCrypt.  The restrictions imposed by my agreement with
  2348. ViaCrypt do not apply outside the USA or Canada.
  2349.  
  2350. Finally, if you want to turn PGP into a commercial product and make
  2351. money selling it, then we must agree on a way for me to also make
  2352. money on it.  If you use PGP in such a manner that you must pay
  2353. patent royalties or any other software licensing fees to the patent
  2354. holders for any cryptographic algorithms used by PGP, then we must
  2355. agree on a way for me to also be paid in some manner.  Buying PGP
  2356. from ViaCrypt is one way to meet this requirement.
  2357.  
  2358.  
  2359. Other Licensing Restrictions
  2360. ----------------------------
  2361.  
  2362. Under no circumstances may PGP be distributed without the PGP
  2363. documentation, including this PGP User's Guide.  And, assuming this is
  2364. an RSAREF version of PGP, the RSAREF license agreement must be kept
  2365. with it.  You must also keep the copyright, patent, and trademark
  2366. notices on PGP and its documentation.
  2367.  
  2368. The standard freeware PGP release is primarily distributed in
  2369. electronic form, as a single compressed archive file, containing a
  2370. collection of files in a "shrink-wrapped" package.  This package
  2371. should not be broken up and the components separately distributed --
  2372. in the interests of quality control, we want to make it difficult for
  2373. users to obtain PGP without getting the full release package.
  2374.  
  2375.  
  2376. Distribution
  2377. ------------
  2378.  
  2379. In the USA, PGP is available for free from the Massachusetts Institute
  2380. of Technology, under the restrictions described above.
  2381.  
  2382. The primary release site for PGP is the Massachusetts Institute of
  2383. Technology, at their FTP site "net-dist.mit.edu", in the /pub/PGP
  2384. directory.  You may obtain free copies or updates to PGP from this
  2385. site, or any other Internet FTP site or BBS that PGP has spread to.
  2386. Don't ask me for a copy directly from me, especially if you live
  2387. outside the US or Canada.  I recommend that you not use any modified
  2388. version of PGP that comes from any other source, other than MIT,
  2389. ViaCrypt, or me, unless it is accompanied by a signed endorsement
  2390. from me personally.  You can get the official release software from
  2391. many other distribution sites "downstream" from MIT.  Hopefully, all
  2392. these other sites are adhering to US export controls.
  2393.  
  2394. The PGP version 2.6.2 executable object release package for MSDOS
  2395. contains the PGP executable software, documentation, RSAREF license,
  2396. sample key rings including my own public key, and signatures for the
  2397. software and this manual, all in one PKZIP compressed file called
  2398. pgp262.zip.  The PGP source release package for MSDOS contains all
  2399. the C source files in one PKZIP compressed file called pgp262s.zip. 
  2400. The filename for the release package is derived from the version
  2401. number of the release.
  2402.  
  2403.  
  2404. Export Controls
  2405. ---------------
  2406.  
  2407. The U.S. Government has made it illegal in most cases to export good
  2408. cryptographic technology, and that may include PGP.  They regard this
  2409. kind of software just like they regard munitions.  This is determined
  2410. not by legislation, but by administrative policies of the State
  2411. Department, Defense Department and Commerce Department.
  2412.  
  2413. The U.S. Government is using export restrictions as a means of
  2414. suppressing both domestic and foreign availability of cryptographic
  2415. technology.  In particular, it is trying to suppress the emergence of
  2416. an international standard for cryptographic protocols, until it can
  2417. establish the Escrowed Encryption Standard (the Clipper chip) as the
  2418. dominant standard.
  2419.  
  2420. Any export restrictions on PGP are imposed by the US Government. 
  2421. This does not imply that I or MIT agree with these restrictions.  We
  2422. just comply with them.  We do not impose additional licensing
  2423. restrictions of our own on the use of PGP outside of the US, other
  2424. than those restrictions that already apply inside the US.  PGP may be
  2425. subject to export controls.  Anyone wishing to export it should first
  2426. consult the State Department's Office of Defense Trade Controls.
  2427.  
  2428. I will not export this software out of the US or Canada in cases when
  2429. it is illegal to do so under US controls, and I urge other people not
  2430. to export it on their own.  If you live outside the US or Canada, I
  2431. urge you not to violate US export laws by getting any version of PGP
  2432. in a way that violates those laws.  Since thousands of domestic users
  2433. got the first version after its initial publication, it somehow
  2434. leaked out of the US and spread itself widely abroad, like dandelion
  2435. seeds blowing in the wind.
  2436.  
  2437. Starting with PGP version 2.0 through version 2.3a, the release point
  2438. of the software has been outside the US, on publicly-accessible
  2439. computers in Europe.  Each release was electronically sent back into
  2440. the US and posted on publicly-accessible computers in the US by PGP
  2441. privacy activists in foreign countries.  There are some restrictions
  2442. in the US regarding the import of munitions, but I'm not aware of any
  2443. cases where this was ever enforced for importing cryptographic
  2444. software into the US.  I imagine that a legal action of that type
  2445. would be quite a spectacle of controversy.
  2446.  
  2447. ViaCrypt PGP is sold in the United States and Canada and is not for
  2448. export.  The following language was supplied by the US Government to
  2449. ViaCrypt for inclusion in the ViaCrypt PGP documentation:  "PGP is
  2450. export restricted by the Office of Export Administration, United
  2451. States Department of Commerce and the Offices of Defense Trade
  2452. Controls and Munitions Control, United States Department of State. 
  2453. PGP cannot be exported or reexported, directly or indirectly, (a)
  2454. without all export or reexport licenses and governmental approvals
  2455. required by any applicable laws, or (b) in violation of any
  2456. prohibition against the export or reexport of any part of PGP."  The
  2457. Government may take the position that the freeware PGP versions are
  2458. also subject to those controls.
  2459.  
  2460. The freeware PGP versions 2.5 and 2.6 were released through a posting
  2461. on a controlled FTP site maintained by MIT.  This site has
  2462. restrictions and limitations which have been used on other FTP sites
  2463. to comply with export control requirements with respect to other
  2464. encryption software such as Kerberos and software from RSA Data
  2465. Security, Inc.  I urge you not to do anything which would weaken
  2466. those controls or facilitate any improper export of PGP.
  2467.  
  2468. Although PGP has become a worldwide de facto standard for E-mail
  2469. encryption, and is widely available overseas, I still get calls from
  2470. people outside the US who ask me if it is legal to use it in their
  2471. own country, for versions that are already available there.  Please
  2472. don't contact me to ask me if it is legal to use PGP in your country
  2473. if you live outside the US.  That question is not up to me.  I've got
  2474. enough legal problems of my own with export control issues, without
  2475. getting involved in giving you legal advice over my phone.  It might
  2476. even put me at some legal risk to simply answer a question like that
  2477. for a foreigner.  If this question concerns you, ask someone else,
  2478. like a lawyer.
  2479.  
  2480. You may have a need to use PGP in a commercial application outside
  2481. the US or Canada.  Unfortunately, at the time of this writing, there
  2482. is no current commercial source for PGP outside the US or Canada.  I
  2483. am trying to find a US-legal way to make a commercially licensed
  2484. version available abroad, but right now the US export restrictions
  2485. make that difficult without putting me at legal risk.  This situation
  2486. may change.
  2487.  
  2488. Some foreign governments impose serious penalties on anyone inside
  2489. their country for merely using encrypted communications.  In some
  2490. countries they might even shoot you for that.  But if you live in
  2491. that kind of country, perhaps you need PGP even more.
  2492.  
  2493.  
  2494.  
  2495. Philip Zimmermann's Legal Situation
  2496. -----------------------------------
  2497.  
  2498. At the time of this writing, I am the target of a US Customs criminal
  2499. investigation in the Northern District of California.  A criminal
  2500. investigation is not a civil lawsuit.  Civil lawsuits do not involve
  2501. prison terms.  My defense attorney has been told by the Assistant US
  2502. Attorney that the area of law of interest to the investigation has to
  2503. do with the export controls on encryption software.  The federal
  2504. mandatory sentencing guidelines for this offense are 41 to 51 months
  2505. in a federal prison.  US Customs appears to be taking the position
  2506. that electronic domestic publication of encryption software is the
  2507. same as exporting it.  The prosecutor has issued a number of federal
  2508. grand jury subpoenas.  It may be months before a decision is reached
  2509. on whether to seek indictment.  This situation may change at any
  2510. time, so this description may be out of date by the time you read
  2511. it.  Watch the news for further developments.  If I am indicted and
  2512. this goes to trial, it will be a major test case.
  2513.  
  2514. I have a legal defense fund set up for this case.  So far, no other
  2515. organization is doing the fundraising for me, so I am depending on
  2516. people like you to contribute directly to this cause.  If you care
  2517. about the future of your civil liberties in the information age, then
  2518. perhaps you will care about this case.  The legal fees are expensive,
  2519. the meter is running, and I need your help.  The fund is run by my
  2520. lead defense attorney, Phil Dubois, here in Boulder.  Please send
  2521. your contributions to:
  2522.  
  2523.    Philip L. Dubois, Lawyer
  2524.    2305 Broadway
  2525.    Boulder, Colorado 80304 USA
  2526.    Phone (303) 444-3885
  2527.    E-mail:  dubois@csn.org
  2528.  
  2529. You can also phone in your donation and put it on Mastercard or Visa.
  2530. If you want to be really cool, you can use Internet E-mail to send in
  2531. your contribution, encrypting your message with PGP so that no one
  2532. can intercept your credit card number.  Include in your E-mail
  2533. message your Mastercard or Visa number, expiration date, name on the
  2534. card, and amount of donation.  Then sign it with your own key and
  2535. encrypt it with Phil Dubois's public key (his key is included in the
  2536. standard PGP distribution package, in the "keys.asc" file).  Put a
  2537. note on the subject line that this is a donation to my legal defense
  2538. fund, so that Mr. Dubois will decrypt it promptly.  Please don't send
  2539. a lot of casual encrypted E-mail to him -- I'd rather he use his
  2540. valuable time to work on my case.
  2541.  
  2542. If you want to read some press stories to find out why this is an
  2543. important case, see the following references:
  2544.  
  2545.   1)  William Bulkeley, "Cipher Probe", Wall Street Journal, Thursday
  2546.       28 April 1994, front page.
  2547.   2)  John Cary, "Spy vs. Computer Nerd:  The Fight Over Data
  2548.       Security", Business Week, 4 Oct 1993, page 43.
  2549.   3)  Jon Erickson, "Cryptography Fires Up the Feds", Dr. Dobb's
  2550.       Journal, December 1993, page 6.
  2551.   4)  John Markoff, "Federal Inquiry on Software Examines Privacy
  2552.       Programs", New York Times, Tuesday 21 Sep 1993, page C1.
  2553.   5)  Kurt Kleiner, "Punks and Privacy", Mother Jones Magazine, 
  2554.       Jan/Feb 1994, page 17.
  2555.   6)  Steven Levy, "Battle of the Clipper Chip", New York Times
  2556.       Magazine, Sunday 12 Jun 1994, page 44.
  2557.   7)  Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54.
  2558.   8)  John Markoff, "Cyberspace Under Lock and Key", New York Times,
  2559.       Sunday 13 Feb 1994.
  2560.   9)  Philip Elmer-DeWitt, "Who Should Keep the Keys", Time, 14 Mar
  2561.       1994, page 90.
  2562.  
  2563. There are a great many other articles on PGP from around the world. 
  2564. I'm keeping a scrapbook.
  2565.  
  2566.  
  2567.  
  2568. Other Sources of Information on PGP
  2569. ===================================
  2570.  
  2571.  
  2572. Where to Get a Commercial Version of PGP
  2573. ----------------------------------------
  2574.  
  2575. To get a fully licensed version of PGP for use in the USA or Canada,
  2576. contact:
  2577.  
  2578.    ViaCrypt
  2579.    9033 North 24th Avenue, Suite 7
  2580.    Phoenix, Arizona 85021  USA
  2581.    Phone: (602) 944-0773, or (800) 536-2664 
  2582.    Fax: (602) 943-2601
  2583.    E-mail: viacrypt@acm.org
  2584.  
  2585. ViaCrypt has a version of PGP for MSDOS, and a number of Unix
  2586. platforms.  They also have a Windows shell version, and other 
  2587. versions are under development, including Macintosh.  If you have a
  2588. need to use PGP in a commercial or Government setting, and ViaCrypt
  2589. has a version of PGP for your hardware platform, you should get
  2590. ViaCrypt PGP.
  2591.  
  2592. ViaCrypt has obtained all the necessary licenses from PKP, Ascom-Tech
  2593. AG, and Philip Zimmermann to sell PGP for use in commercial or
  2594. government environments.  ViaCrypt PGP is every bit as secure as the
  2595. freeware PGP, and is entirely compatible in both directions with the
  2596. freeware version of PGP.  ViaCrypt PGP is the perfect way to get a
  2597. fully licensed version of PGP into your corporate environment.
  2598.  
  2599. If you work in a large company and you are a fan of PGP, I urge you
  2600. to try to persuade your company to buy lots of copies of PGP from
  2601. ViaCrypt.  Not just because that will earn royalties for me.  If
  2602. ViaCrypt can make PGP a commercial success, it will go a long way
  2603. toward cementing PGP's political future as an unstoppable standard
  2604. for E-mail encryption in the corporate world.  The corporate world is
  2605. where the money is, and that affects public policy like nothing
  2606. else.  And that includes Government policy to suppress strong
  2607. cryptography.
  2608.  
  2609.  
  2610.  
  2611. Reporting PGP Bugs
  2612. ------------------
  2613.  
  2614. Bugs in PGP should be reported via E-mail to MIT, the official
  2615. distribution site of PGP.  The E-mail address for bug reports is
  2616. pgp-bugs@mit.edu.  MIT will forward a copy of your bug report to me. 
  2617. When you report bugs, be sure to specify what machine and operating
  2618. system you are using and what version of PGP you have, and provide
  2619. enough detail to reproduce the problem.  It would also be a good idea
  2620. to find out if you have the latest version of PGP, in case the bug
  2621. has already been fixed.  Also, it's a good idea to make sure it
  2622. really is a bug before you report it.  RTFM.
  2623.  
  2624.  
  2625.  
  2626. Fan Mail, Updates, and News
  2627. ---------------------------
  2628.  
  2629. After all this work I have to admit I wouldn't mind getting some fan
  2630. mail for PGP, to gauge its popularity.  Let me know what you think
  2631. about it and how many of your friends use it.  Bug reports and
  2632. suggestions for enhancing PGP are welcome, too.  Perhaps a future PGP
  2633. release will reflect your suggestions.  
  2634.  
  2635. This project has not been funded and the project has nearly eaten me
  2636. alive.  This means you usually won't get a reply to your mail, unless
  2637. you only need a short written reply and you include a stamped
  2638. self-addressed envelope.  But I often do reply to E-mail.  Please
  2639. keep it in English, as my foreign language skills are weak.  If you
  2640. call and I'm not in, it's best to just try again later.  I usually
  2641. don't return long distance phone calls, unless you leave a message
  2642. that I can call you collect, and even then I might not return your
  2643. call.  If you need any significant amount of my time, I am available
  2644. on a paid consulting basis, and I always return those calls.
  2645.  
  2646. The most inconvenient mail I get is for some well-intentioned person
  2647. to send me a few dollars asking me for a copy of PGP.  I don't send 
  2648. it to them because I'd rather avoid any legal problems with PKP.  Or
  2649. worse, sometimes these requests are from foreign countries, and I
  2650. would be risking a violation of US cryptographic export control
  2651. laws.  Even if there were no legal hassles involved in sending PGP to
  2652. them, they usually don't send enough money to make it worth my time.
  2653. I'm just not set up as a low cost low volume mail order business.  I
  2654. can't just ignore the request and keep the money, because they
  2655. probably regard the money as a fee for me to fulfill their request.
  2656. If I return the money, I might have to get in my car and drive down
  2657. to the post office and buy some postage stamps, because these
  2658. requests rarely include a stamped self-addressed envelope.  And I
  2659. have to take the time to write a polite reply that I can't do it.  If
  2660. I postpone the reply and set the letter down on my desk, it might be
  2661. buried within minutes and won't see the light of day again for
  2662. months.  Multiply these minor inconveniences by the number of
  2663. requests I get, and you can see the problem.  Isn't it enough that
  2664. the software is free?  It would be nicer if people could try to get
  2665. PGP from any of the myriad other sources.  If you don't have a modem,
  2666. ask a friend to get it for you.  If you can't find it yourself, I
  2667. don't mind answering a quick phone call.
  2668.  
  2669. If anyone wants to volunteer to improve PGP, please let me know.  It
  2670. could certainly use some more work.  Some features were deferred to
  2671. get it out the door.  A number of PGP users have since donated their
  2672. time to port PGP to Unix on Sun SPARCstations, to Ultrix, to VAX/VMS,
  2673. to OS/2, to the Amiga, and to the Atari ST.  Perhaps you can help
  2674. port it to some new environments.  But please let me know if you plan
  2675. to port or add enhancements to PGP, to avoid duplication of effort,
  2676. and to avoid starting with an obsolete version of the source code.  
  2677.  
  2678. Because so many foreign language translations of PGP have been
  2679. produced, most of them are not distributed with the regular PGP
  2680. release package because it would require too much disk space. 
  2681. Separate language translation "kits" are available from a number of
  2682. independent sources, and are sometimes available separately from the
  2683. same distribution centers that carry the regular PGP release
  2684. software.  These kits include translated versions of the file 
  2685. LANGUAGE.TXT, PGP.HLP, and the PGP User's Guide.  If you want to
  2686. produce a translation for your own native language, contact me first
  2687. to get the latest information and standard guidelines, and to find
  2688. out if it's been translated to your language already.  To find out
  2689. where to get a foreign language kit for your language, you might
  2690. check on the Internet newsgroups, or get it from Mike Johnson
  2691. (mpj@csn.org).
  2692.  
  2693. If you have access to the Internet, watch for announcements of new
  2694. releases of PGP on the Internet newsgroups "sci.crypt" and PGP's own
  2695. newsgroup, "alt.security.pgp".  If you want to know where to get PGP,
  2696. MIT is the primary FTP distribution site (net-dist.mit.edu).  Or ask
  2697. Mike Johnson (mpj@csn.org) for a list of Internet FTP sites and BBS
  2698. phone numbers.
  2699.  
  2700.  
  2701.  
  2702. Computer-Related Political Groups
  2703. ---------------------------------
  2704.  
  2705. PGP is a very political piece of software.  It seems appropriate to
  2706. mention here some computer-related activist groups.  Full details on
  2707. these groups, and how to join them, is provided in a separate
  2708. document file in the PGP release package.
  2709.  
  2710. The Electronic Privacy Information Center (EPIC) is a public interest
  2711. research center in Washington, DC.  It was established in 1994 to
  2712. focus public attention on emerging privacy issues relating to the
  2713. National Information Infrastructure, such as the Clipper Chip, the
  2714. Digital Telephony proposal, medical record privacy, and the sale of
  2715. consumer data.  EPIC is sponsored by the Fund for Constitutional
  2716. Government and Computer Professionals for Social Responsibility. 
  2717. EPIC publishes the EPIC Alert and EPIC Reports, pursues Freedom of
  2718. Information Act litigation, and conducts policy research on emerging
  2719. privacy issues.  For more information email info@epic.org, or write
  2720. EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003.
  2721. +1 202 544 9240 (tel), +1 202 547 5482 (fax).
  2722.  
  2723. The Electronic Frontier Foundation (EFF) was founded in 1990 to
  2724. assure freedom of expression in digital media, with a particular
  2725. emphasis on applying the principles embodied in the US Constitution
  2726. and the Bill of Rights to computer-based communication.  They can be
  2727. reached in Washington DC, at (202) 347-5400.  Internet E-mail address:
  2728. eff@eff.org.
  2729.  
  2730. Computer Professionals For Social Responsibility (CPSR) empowers
  2731. computer professionals and computer users to advocate for the
  2732. responsible use of information technology and empowers all who use
  2733. computer technology to participate in public policy debates on the
  2734. impacts of computers on society.  They can be reached at:
  2735. (415) 322-3778 in Palo Alto, E-mail address cpsr@csli.stanford.edu.
  2736.  
  2737. The League for Programming Freedom (LPF) is a grass-roots
  2738. organization of professors, students, businessmen, programmers and
  2739. users dedicated to bringing back the freedom to write programs.  They
  2740. regard patents on computer algorithms as harmful to the US software
  2741. industry (and so do I!).  They can be reached at (617) 433-7071. 
  2742. E-mail address: lpf@uunet.uu.net.
  2743.  
  2744. For more details on these groups, see the accompanying document in
  2745. the PGP release package.
  2746.  
  2747.  
  2748.  
  2749. Recommended Readings
  2750. --------------------
  2751.  
  2752.  
  2753. Introductory Readings
  2754.  
  2755. 1)  Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and
  2756.     Source Code in C", John Wiley & Sons, 1993
  2757.     (This book is a watershed work on the subject.)
  2758. 2)  Dorothy Denning, "Cryptography and Data Security", Addison-Wesley,
  2759.     Reading, MA 1982
  2760. 3)  Dorothy Denning, "Protecting Public Keys and Signature Keys",
  2761.     IEEE Computer, Feb 1983
  2762. 4)  Martin E. Hellman, "The Mathematics of Public-Key Cryptography," 
  2763.     Scientific American, Aug 1979
  2764. 5)  Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54.
  2765.     (A "must-read" article on PGP and other related topics.)
  2766. 6)  Steven Levy, "Battle of the Clipper Chip", New York Times
  2767.     Magazine, Sunday 12 Jun 1994, page 44. (Great article, great
  2768.     photos.)
  2769. 7)  William Bulkeley, "Cipher Probe", Wall Street Journal, 28 April
  2770.     1994, front page.  (An article on PGP and Zimmermann.)
  2771.  
  2772.  
  2773. Other Readings
  2774.  
  2775. 8)  Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory
  2776.     for Computer Science, 1991
  2777. 9)  Xuejia Lai, "On the Design and Security of Block Ciphers", 
  2778.     ETH Series on Information Processing (Ed. J. L. Massey),
  2779.     Vol. 1, Hartung-Gorre Verlag, Konstanz, Switzerland, 1992
  2780. 10) Philip Zimmermann, "A Proposed Standard Format for RSA 
  2781.     Cryptosystems", Advances in Computer Security, Vol III, edited by
  2782.     Rein Turn, Artech House, 1988
  2783. 11) Paul Wallich, "Electronic Envelopes", Scientific American, Feb
  2784.     1993, page 30.  (An article on PGP)
  2785. 12) William Stallings, "Pretty Good Privacy", BYTE, July 1994, page
  2786.     193
  2787. 13) Philip Zimmermann, "The Official PGP User's Guide", MIT Press,
  2788.     1994 (in press)
  2789. 14) Philip Zimmermann, "PGP Source Code and Internals", MIT Press,
  2790.     1994 (in press)
  2791.  
  2792.  
  2793.  
  2794. To Contact the Author
  2795. ---------------------
  2796.  
  2797. Philip Zimmermann may be reached at:
  2798.  
  2799. Boulder Software Engineering
  2800. 3021 Eleventh Street
  2801. Boulder, Colorado 80304  USA
  2802. Internet:  prz@acm.org
  2803. Phone (303) 541-0140 (voice)  (10:00am - 7:00pm Mountain Time)
  2804. Fax available, if you arrange it via voice line.
  2805.  
  2806.  
  2807.  
  2808. Appendix A:  Where to Get PGP
  2809. =============================
  2810.  
  2811. The following describes how to get the freeware public key
  2812. cryptographic software PGP (Pretty Good Privacy) from an anonymous
  2813. FTP site on Internet, or from other sources.  
  2814.  
  2815. PGP has become a worldwide de facto standard for E-mail encryption.
  2816. PGP has sophisticated key management, an RSA/conventional hybrid 
  2817. encryption scheme, message digests for digital signatures, data
  2818. compression before encryption, and good ergonomic design.  PGP is
  2819. well featured and fast, and has excellent user documentation.  Source
  2820. code is free.
  2821.  
  2822. The Massachusetts Institute of Technology is the distributor of PGP
  2823. version 2.6, for distribution in the USA only.  It is available from
  2824. "net-dist.mit.edu," a controlled FTP site that has restrictions and
  2825. limitations, similar to those used by RSA Data Security, Inc., to comply
  2826. with export control requirements.  The software resides in the directory
  2827. /pub/PGP.
  2828.  
  2829. A reminder:  Set mode to binary or image when doing an FTP transfer.
  2830. And when doing a kermit download to your PC, specify 8-bit binary
  2831. mode at both ends.
  2832.  
  2833. You can also obtain PGP from MIT via the World-Wide Web at
  2834. http://web.mit.edu/network/pgp.html.
  2835.  
  2836. There are two compressed archive files in the standard release, with
  2837. the file name derived from the release version number.  For PGP
  2838. version 2.6.2, you must get pgp262.zip which contains the MSDOS
  2839. binary executable and the PGP User's Guide, and you can optionally
  2840. get pgp262s.zip which contains all the source code.  These files can
  2841. be decompressed with the MSDOS shareware archive decompression
  2842. utility PKUNZIP.EXE, version 1.10 or later.  For Unix users who lack
  2843. an implementation of UNZIP, the source code can also be found in the
  2844. compressed tar file pgp262s.tar.Z.
  2845.  
  2846. If you don't have any local BBS phone numbers handy, here is a BBS
  2847. you might try.  The Catacombs BBS, operated by Mike Johnson in
  2848. Longmont, Colorado, has PGP available for download by people in the US
  2849. or Canada only.  The BBS phone number is 303-772-1062.  Mike
  2850. Johnson's voice phone number is 303 772-1773, and his E-mail address
  2851. is mpj@csn.org.  Mike also has PGP available on an Internet FTP site
  2852. for users in the US or Canada only; the site name is csn.org, in
  2853. directory /mpj/, and you must read the README.MPJ file to get it.
  2854.  
  2855. To get a fully licensed version of PGP for use in the USA or Canada,
  2856. contact ViaCrypt in Phoenix, Arizona.  Their phone number is
  2857. 602-944-0773.  ViaCrypt has obtained all the necessary licenses from
  2858. PKP, Ascom-Tech AG, and Philip Zimmermann to sell PGP for use in
  2859. commercial or Government environments.  ViaCrypt PGP is every bit as
  2860. secure as the freeware PGP, and is entirely compatible in both
  2861. directions with the freeware version of PGP.  ViaCrypt PGP is the
  2862. perfect way to get a fully licensed version of PGP into your
  2863. corporate or Government environment.
  2864.  
  2865. Here are a few people and their E-mail addresses or phone numbers you
  2866. can contact in some countries to get information on local PGP 
  2867. availability for versions earlier than 2.5:
  2868.  
  2869. Peter Gutmann                Hugh Kennedy
  2870. pgut1@cs.aukuni.ac.nz        70042.710@compuserve.com
  2871. New Zealand                    Germany
  2872.  
  2873. Branko Lankester            Miguel Angel Gallardo
  2874. branko@hacktic.nl            gallardo@batman.fi.upm.es
  2875. +31 2159 42242                (341) 474 38 09
  2876. The Netherlands                Spain
  2877.  
  2878. Hugh Miller                    Colin Plumb
  2879. hmiller@lucpul.it.luc.edu    colin@nyx.cs.du.edu
  2880. (312) 508-2727                Toronto, Ontario, Canada
  2881. USA
  2882.  
  2883. Jean-loup Gailly
  2884. jloup@chorus.fr
  2885. France
  2886.  
  2887.